On Fri, May 30, 2008 at 2:13 PM, Bill Schwab <[EMAIL PROTECTED]> wrote: > The above said, I have considered doing something like your rewrite to fix > stream method naming snags. Consider #next. As we have discussed, I think > it should be named #nextOrNil, allowing #next to behave as it does in > Dolphin. Yes, I have a bias toward Dolphin, but I also consider its streams > to be elegantly/correctly built. > > One way to fix it would be to transform #next into #nextOrNil (which is what > Squeak's #next does), and then add a #next that signals EndOfStream on > exhaustion;
I agree. > EndOfStream would have no default action in this scenario. If we could > further transform any idioms such as > > aStream next ifNotNil:[ :x | ... ] > > into > > aStream nextIfPresent:[ :x | ... ] > > etc., that could be great if we did it well. Even a clean change to > #nextOrNil would allow us to make an otherwise breaking change as painlessly > as possible. > > FWIW, I have no direct problem with #on:, though I see where you are going. > We might get a similar benefit by simply changing ReadStream in the system > dictionary, making it an alias for NSReadStream?? Even without talking about Nile, I think it is a good thing to avoid direct references to ReadStream. This also renders the code more readable. A third benefit is that #readStream could now be implement differently on different kind of streamable things. In Nile for example, String overrides #readStream to return an improved ReadStream for strings. -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu) _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
