Stef, I will see what I can do. I want to make my changes available, as I think they should be widely used, and it would nice to have them in the mainstream Pharo so that at least I can release code depending one them. I still think the correct action is to fix the behavior, but I am not optimistic. VW's #next has the same willingness to answer nil vs. raise an exception, and they too are hesitant to fix it for fear of breaking existing code. In Squeak/Pharo, #next: is also affected, doing what should be reserved for #nextAvailable:. The idea is to have "honest" semantics, in which there are strict and truncating versions of the selectors, putting thep programmer in charge. The strict versions do not answer nil; they raise and exception, calling attention to the failure vs. making the caller dig for it. Not being optimisic about a fix, I created new selectors that work as advertised, and have deprecated the ones that can fail silently. #nextLine is easier to call buggy, as the implementation details (specifically whether or not it can return nil - something it should not do IMHO) depends on the receiving class. It seems to me that one should be able to change stream type and get results that are as similar as possible, within the limits of generating and non-generating streams, of course. I will wrap what I can of this into some tests. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Saturday, June 06, 2009 3:40 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Streams - #nextLine On Jun 6, 2009, at 7:15 PM, Schwab,Wilhelm K wrote:
Stef,
I can certainly write some tests. Of course, they would have to start with a bias toward one behavior (I suggest never answering nil), and then illustrate the differences in behavior. Is that what you want to see?
yes :) The problem is that I do not have a clear picture of the problem solution and pros and cons (Ansi???) So if you can try in simple emglish to phrase the three following paragraph I think that we could use it as a template and instance for Request for Improvement.
In terms of my modified methods (#nextOne, etc.), I consider them a compromise, but a necessary one. I can create tests to illustrate their use, but the real focus is to avoid silent failures. VW even has a trap in that (IIRC) #next will answer nil, but they get #next: right. They were willing to discuss a breaking change, but decided against doing it, so I "gave up" and decided to create my own robust set of selectors.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Saturday, June 06, 2009 8:04 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Streams - #nextLine
Hi bill
do you have a couple of unit tests so that we can really give you an answer?
Stef On Jun 6, 2009, at 1:19 AM, Schwab,Wilhelm K wrote:
Hello all,
You might recall my advocating breaking changes to #next, #next: and company: these methods do not behave as advertised, answering nil vs. raising an exception when reading off the back of a stream. It was fairly clear that the will did not exist to make he required changes, so I have put myself on a strict diet of #nextOne, #nextMany:, #nextAvailable: that *do* work as expected. I plan to make code for these methods available to all, and strongly recommend using them.
My initial efforts with Citezen have convinced me that I am correct to demand that code function as advertised/expected. I lost a couple of hours trying to sort out whether I was faced with a debugger defect, but ended up finding a source of inconsistency among like-named methods. Look at implementors of #nextLine. First, this is perhaps ambiguous given Pharo's cross-platform nature - it might be wise to always specify CrLf or simply Lf??? Beyond that, some implementations answer nil (why is beyond me, as it leaves callers with two things to check when #notEmpty would otherwise almost always suffice).
Any thoughts? If nothing else, I think the various #nextLine methods should behave alike, and as you can tell, I strongly favor answering empty vs. nil.
Bill
_______________________________________________ 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
_______________________________________________ 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