[Squeakfoundation]re: Flow integration

Michael Rueger squeakfoundation@lists.squeakfoundation.org
Fri, 22 Nov 2002 09:14:37 -0800


Daniel Vainsencher wrote:
> Let me summarize the points so far -

> 4. Backwards compatibility - 

There is no such thing when you replace seriously broken code. Period.
Which means that I conciously made the decision to not care if my 
network rewrite breaks existing code (that is code currently not in the 
image).
Having said that we should only break this code once. Meaning whatever 
rewritten code gets into the update stream (soon?) should define an API 
that then newer versions should be backwards compatible to.

> 5. Proposals to take the primitive interfaces but not the stream
> refactoring
>  - I can't summarize this because there were no specific
> proposal/problems raised (Michael? Goran?)

I have to think more about this and tinker with some code to make a real 
proposal. It's more of a gut feeling that it shouldn't be too hard to 
exchange the current primitive layer with the Flow one without breaking 
other parts of the system. I just don't really know yet.

It would be different for the stream refactoring which is a whole can of 
worms for itself. Stephen Pair and I had a lengthy discussion on it and 
we finally agreed that refactoring the stream hierarchy only makes sense 
using traits.
Unless you take up my proposal:

Stream (resource)
    InternalStream
    ExternalStream

;-)


> 5 - Michael, could you please clarify you intent here? I'm not sure
> whether your comments here are about transition or the desireability of
> the refactoring itself.

See above...
I would like to see the network api and flow exchangeable (not 
co-existent, that's <censored>). The Stream refactoring should wait 
IMHO, although some of the flow ideas should be incorporated 
(NetStreams) to define a new compatible network/external resource API.

Michael