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