AFAICT, what we're saying complements. For things too large to process
in one release cycle, break them up into smaller pieces. 

For each smaller piece, have a clearly defined migration path that
doesn't force the users hand. Some good solutions are -
* be compatible with previous API and semantics
* make the new thing not clash with the old, as you describe previously.
* If things must break (we want API changes), use deprecation as the KCP
project does.

I think the first part is the main issue with Flow - it simply changes
lots of things. If it were "merely" an alternative Streams hierarchy, we
could handle it with some class name changes and deprecation. But it
also (IIRC) separates resources from streams, and changes the
primitives, and requires threads which not all platforms have and so
on...

Daniel

Andreas Raab <andreas.raab at gmx.de> wrote:
> Daniel,
> 
> Certainly true for the "bits and pieces" surrounding the design, but
> considering that (for example) Flow is an entire replacement of the stream
> hierarchy, it doesn't solve the problem that some things will (have to)
> break during the migration process. The most important part for me in this
> area is to be able to have a clearly defined migration path which leaves
> things "working by default" while things are being migrated (similar to the
> deprecation machinery used by KCP) can be used in parallel with the set of
> classes being out-phased (that's why I said don't touch the existing stuff)
> and then easily switched over once the major part of migration is finished.
> 
> Cheers,
>   - Andreas
> 
> > -----Original Message-----
> > From: squeak-dev-bounces at lists.squeakfoundation.org 
> > [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> > Behalf Of Daniel Vainsencher
> > Sent: Thursday, July 24, 2003 11:42 PM
> > To: The general-purpose Squeak developers list
> > Subject: RE: [ENH] SocketStream ascii/binary and nextAvailable
> > 
> > 
> > Or reformulate the change as a series of smaller changes. 
> > This is almost
> > always more work for the originator, but it is much easier 
> > for others to
> > evaluate and thus accept.
> > 
> > For example, I think IOHandle does something similar to part 
> > of Flow. It
> > may not solve all the problems Flow solves, but it'd be 
> > easier to accept
> > IOHandle (or its flow equivalent) and then the rest of Flow than to
> > accept all of Flow at once.
> > 
> > Daniel
> > 
> > Andreas Raab <andreas.raab at gmx.de> wrote:
> > > > How are we going to do that? Are we ever going to make such a big 
> > > > refactoring? Is such a big change ever going to make it 
> > to the update 
> > > > stream?
> > > 
> > > If you're real about making such a thing the best (only?) 
> > way to do this is
> > > to build an entire parallel class hierarchy which can 
> > replace the entire
> > > subsystem. Just give your classes prefixes so that they can 
> > be loaded in
> > > parallel to any existing clients, develop them up to the 
> > point where you
> > > consider them stable and then migrate the existing clients. 
> > At that point,
> > > you can dump the old subsystem (put it on SqueakMap for 
> > anyone who still
> > > needs it) and just rename your entire class hierarchy.
> > > 
> > > In other words, absolutely _don't_ touch or change anything 
> > in the existing
> > > subsystem (this is one of the major problems with Flow - 
> > last time I tried
> > > it created some serious problems with clients which weren't 
> > migrated which
> > > makes loading it a risky and painful exercise) - after all 
> > if you're talking
> > > about a serious rewrite, you can as well copy a few 
> > classes, can't you?
> > > (hint: in the Browser use "copy class" to get a starting point).
> > > 
> > > Cheers,
> > >   - Andreas
> >