Hi Craig and guys!

--- Craig Latta <Craig.Latta at NetJam.ORG> wrote:
> Hi Göran--
> 
> > Changed back from my "foray into Flow land"...
> 
> 	I'd appreciate any feedback from your foray. :)

Is "foray" the right word? It was a shot in the dark - but I think I spelled it right and that it
means approximately what I think it does... :-)

> 
> 	thanks,

Yes, of course. Let me first state that I like a lot of the stuff in Flow. Seems like a solid
effort overall. I loaded up Johns port to "standard Squeak" and used the Client and Server classes
(well, Sqcvs only used Client, actually I also used/use it in another project we have, but that is
another story.)

What made me drop it:

1. Since I only needed a little better Socket support than Squeak has Flow turned out to be
overkill. Yesterday I moved over to using only two classes from Comanche instead and it works
good.

2. There where strange "glitches" in that particular Flow I used. Actually there was a test
blowing up and we got an exception deep down from time to time. I can dig that up if you want to
but remember that this probably is only present in Johns port (my guess).

3. Since Sqcvs is meant to be easily usable in standard Squeak, Flow felt a little bit heavy as a
prerequisite. Johns port is probably "dying" and standard Flow is (last I looked) not a simple
filein for standard Squeak.

4. I remember that I reacted on two "stylish" issues of the code. First there where a bunch of
methods added to base classes that I really didn't feel necessary. And at least one of them (an
#if...: method) didn't feel like an approvement - it made me dizzy. :-) Then there was a style
promoting "extension by inheritance" (the Client and Server classes) with a lot of small methods
being sent that should/could be overridden like #binary etc. Over time I have realized that I
personally rather like promoting "extension by composition" (or whatever you like to call it)
instead. More of a "Keep it simple, stupid" approach. I often find myself forced to change the
superclasses even though they are carefully crafted to prevent exactly that. And then the "win" is
lost - all left is a complicated inheritance relationship making the code less readable. In short
- even though Flow feels carefully designed and full of good design btw - it also felt a teeny bit
"overdesigned" in places. A very common trap that I often fall into myself I might add. I might
even have done that in Sqcvs where I also use inheritance quite a lot - it would be interesting to
hear a review on that design because I haven't decided myself if it is good or bad. Sofar it works
- but that might be just because I know my own code... ;-) Anyway, this part turned into a rant -
that was not my intention. Please do not get offended by it!

As a final note - I am somewhat aware of the politics around Flow (exceptions, socket primitives,
licensing etc) and I for one would be very glad to see Flow (in some incarnation) as a future
"base module" for standard Squeak. So looking only at Flow, disregarding the context of Sqcvs and
the current situation (where Flow is not in standard Squeak), I think my only "gripe" with it is
bullet 4 above. But that is probably a small (and even fixable) gripe - we all program in
different styles!

Anyway, feel free to ask for more details on this.

regards, Göran

=====
Göran Hultgren, goran.hultgren at bluefish.se
GSM: +46 70 3933950, http://www.bluefish.se
"Department of Redundancy department." -- ThinkGeek

__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com