Andreas Raab a écrit :
I mean that some of the basics of the Squeak stream hierarchy got put into place some twenty years ago and some assumptions simply changed over time. I would expect the same to be true for Nile, in particular if the quantitative reuse of traits is higher. For example, consider that a trait defines an operation that raises an exception (#next anyone? ;-) and that five years later you figured you were wrong and that you'd rather have it silently return nil. Can you fix that at this point? Seems *very* unlikely if those traits are widely used. So what happens is that every "new" user of that trait will start overwriting the method so you get into precisely the same situation as with the current collection hierarchy. It seems unavoidable in the long term that some of these issues will happen (and yes, "in theory" all of that is fixable but I'm talking about a practical situation).
Cheers,
- Andreas
Hello Andreas, If you insist on it, yes, I must agree that answering nil at the end of a Character Stream is a good trade-off and a simple lightweight implementation. (Due to low cost of == nil, Exception becomes faster only for large files). But, it is also a very dumb thing to do with generic Streams of Objects:
Collection allSubInstances count: [:e | [e includes: nil] ifError: [false]].
My image counts 16785 such nil holders...
Cheers