[Pharo-project] pharo vision
nicolas.cellier.aka.nice at gmail.com
Mon Jan 30 17:27:43 CET 2012
I think the best option with Xtreams
(http://code.google.com/p/xtreams/ ) is to rewrite client code.
This is why the designers have chosen a set of new selectors.
If we think it's time to remove some cruft, but still have late client
adopters, we could also write a wrapper providing old Stream API in
'foo' reading withStreamAPI
Then replace ReadStream/WriteStream with such factory...
Of course, replicating the whole zoo of specialized selectors of
current Stream library is not an option IMO.
2012/1/30 Henrik Johansen <henrik.s.johansen at veloxit.no>:
> On Jan 30, 2012, at 9:24 14AM, Stéphane Ducasse wrote:
> Some comments on the parts I'm most familiar with:
> I agree, the nice parts in FS to me is the path manipulation API.
> Going back to pure ANSI-streams as provided by FSFileStream is not really an
> Since it's a clean break from FileDirectory & friends though, it might be
> the perfect time to introduce XTreams; -or it might be too much hassle to
> have to change both parts in existing code at once.
> A good compromise would be to make it pluggable, using the existing
> Standard/MultiByteFileStreams by default, but making XStreams pluggable (on
> a use--by-use basis, so you can write new code with XStreams while
> maintaining old code where you have only had time to rewrite the path
> "Using ephemerons we can then simplify the Announcement and make sure that
> clients do not have to worry about weak or not registration."
> You still have to worry about whether you want weak or strong registration.
> "Do I have strict requirements for when the announcement should stop being
> delivered in relation to subscriber lifespan?" is still a valid question.
> What you don't have to worry about, is what _type_ of subscription (action
> blocks or message sends), you are allowed to use when registering weakly.
> Ends with "In addition, " then nothing :)
More information about the Pharo-project