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? 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