Stef, A statement on pros/cons sounds like a good place to start. Re the VW/Dolphin behavior, the way to look at the errors is that they tell you what went wrong and where. If the errors truly are superfluous, then you probably should be using #nextAvailable:, which truncates and does not raise errors.
You asked about a backwardly compatible solution. I think the pluggable exception idea is probably the best bet for that. Bill -----Original Message----- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Tuesday, June 09, 2009 3:20 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] About EndOfStream notification [was Streams - #nextLine] > Nicolas, > > Adding #nextAvailable: hurts nothing, but changing #next: (and #next > too) will break existing code. In VW, it is only #next that has the > silent failure trap, and while Cincom was willing to consider a > change, they ultimately declined to make it. I am convinced that > Dolphin gets it right, but I would be surprised to see us adopt its > behavior. I would be thrilled if we did so, but doubt it will happen. > Failing such breaking changes, I need to create a way to have my code > work, which is why I started adding my own methods. > > Your pluggable exception/defaultAction idea is worth a shot. Some > simple testing should show whether it can preserve current behavior > and throw exceptions, respectively. I think I heard Stef as much as > say he would support it if it does serve both masters. Stef? As I said I would like to have a one page description of the problem, solution, pros and cons May be put it on the wiki Right now we are messy in terms of process for changes. I personnally always hated the VW behavior because we lost a lot of time with code trapping error. But I do not want to take decision on my emotion because I could be wrong. So do a one page proposal with problem, solution, pros and cons. Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
