[Squeakfoundation]re: Flow integration

Thu, 21 Nov 2002 19:01:43 -0800

Hi-
As a completely naive user -- could you not make the 'old; stuff become a loadable
package?
David

Craig Latta wrote:

> Hi Andreas--
>
> > You fixed all references... you knew about.
>
>         That's not the end of the process. :)  I think you're missing my intent
> that those changes be temporary. The full integration process would go
> like this:
>
> 1.      Change some of the original class names ("Stream" becomes
> "OldStream", etc.)
> 2.      Fix references to those classes. Everything keeps working during the
> rest of the integration process.
> 3.      Install new classes (several of which use the original names, and
> provide backward-compatible protocol).
> 4.      Incrementally change the above references to use the original class
> names again (references to "OldStream" become references to "Stream",
> which is the new but backward-compatible implementation, etc.)
> 5.      The users of internal streams will see no cumulative change, since
> the Flow support for internal streams provides complete backward
> compatibility. The users of other support (e.g., sockets) can decide
> whether to use the new or old framework.
> 6.      As we wish, we can incrementally remove the backward compatibility
> and old framework support (perhaps over a very long period of time).
>
>         The Flow 2a release implements steps 1 to 3, I'm proposing to finish
> the process. Given this process, I don't think your analogies to 3.3
> modules or Croquet (or Microsoft :) are valid.
>
> > ...why not just keep the two hierarchies just completely disjunct?
>
>         Because, e.g., I think what I call "Socket" should be called "Socket".
> :)  As I see it, there is a genuine ontological conflict between the
> current mainstream implementation and mine. And after renaming the
> mainstream classes (which, for the reasons above, I think is no big
> deal), they *are* disjunct. :)
>
>         More seriously, I think it's very important to have the right names for
> things. Sure, one normally makes a file stream by evaluating an
> expression which doesn't refer to the actual instantiating class, but I
> think the system is easier to use if people run into appropriately
> evocative names for things in the system browsers, and this ease of use
> is critical.
>
> > Well if flow can't support those [thread-less] platforms at all...
>
>         Um, I just said I think it can...
>
> > ...just for the record - I am still waiting for benchmarks which
> > actually indicate that flow makes any noticable difference in speed
> > ;-)
>
>         The reality of spare-time programming being what it is, if you want
> *me* to provide these benchmarks, you'll have to be prepared to wait
> until there are real applications I care about. :)
>
>         Please remember that my primary motivation in designing Flow the way I
> did was programming simplicity, not performance. It so happens that I
> also think that it will also be faster. But I don't start profiling
> things until they perform meaningful work. I haven't made time to write
> applications yet, mostly because the ones I want rely on yet more
> infrastructure that has little to do with streaming (how to store mail,
> how to represent system changes, etc.). (I don't mean this as a dig
> against, e.g., Celeste or Scamper, although I must admit I don't use
> them.)
>
>         But while you're waiting, please feel free to send tests that *you*
> would consider meaningful. :)
>
> > > It seems quite feasible to me, by using Smalltalk threads that
> > > simulate some of what the host threads do in the current Flow
> > > implementation (not entirely unlike what happens in the mainstream
> > > Squeak system currently).
> >
> > This isn't quite what I meant.
>
>         I know, but I stand by my answer. :)
>
> > The question was more like: Is it possible to write an implementation
> > of the socket primitives that adheres exactly to the specification of
> > the primitives which may not use a threaded implementation?
>
>         Sure, but I'd rather keep that simulation at the more malleable
> object-memory level.
>
> > Typically, it's best to stay compatible at the primitive level so that if
> > there's a certain behavior expected by the ST code it should be able to rely
> > on it.
>
>         Sure again, but Flow's design allows that behavior to be provided
> either by "auxilliary primitives" (which aren't called directly by
> Smalltalk code) or by yet more Smalltalk code. I'd rather go the
> Smalltalk route.
>
> > At the very least I wouldn't expect people running on HP-UX (which
> > IIRC, has horribly broken pthreads) to expect that they have to
> > "reprogram flow" in order to get something to run which works
> > perfectly well on Linux.
>
>         Right, they wouldn't. Squeak would know what platform it's on, and act
> accordingly.
>
>         By the way, HP-UX has had perfectly fine pthreads since version 11.0
> (two years ago). (Before that, it had DCE threads, which were indeed
> problematic.)
>
> > ...there are lots of platforms that Squeak can run on and some of
> > them already have and more will have networking capabilities [but
> > not properly functioning threads]. And I don't want to arbitrarily
> > limit those...
>
>         As I said, I think we can accomodate those platforms too.
>
>         thanks,
>
> -C
>
> --
> Craig Latta
> improvisational musical informaticist
> craig@netjam.org
> www.netjam.org/resume
> Smalltalkers do: [:it | All with: Class, (And love: it)]
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation

--
David Harris
  OmniPort Home Page:  http://www3.telus.net/OmniPort1/
    Discussion egroup: http://groups.yahoo.com/group/OmniPort
    Swiki:  http://omniport.swiki.net/1