Streams - #nextLine

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 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: [hidden email] [mailto:[hidden email]
> ] On Behalf Of Stéphane Ducasse
> Sent: Saturday, June 06, 2009 8:04 AM
> To: [hidden email]
> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 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: [hidden email] [mailto:[hidden email]
> ] On Behalf Of Stéphane Ducasse
> Sent: Saturday, June 06, 2009 8:04 AM
> To: [hidden email]
> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse
> Sent: Saturday, June 06, 2009 3:40 PM
> To: [hidden email]
> 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: [hidden email] [mailto:[hidden email]
>> ] On Behalf Of Stéphane Ducasse
>> Sent: Saturday, June 06, 2009 8:04 AM
>> To: [hidden email]
>> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Lambdas are relegated to relative obscurity until Java makes them
> popular by not having them." James Iry
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 2009/6/8 Damien Cassou <[hidden email]>:
>> On Sun, Jun 7, 2009 at 2:15 AM, Nicolas
>> Cellier<[hidden email]> wrote:
>>> Before adding a new set of messages, why not make the endOfStream pluggable?
>>
>> I'm not sure it will work because different methods will expect
>> different behavior. Thus these methods won't be able to communicate
>> with the same stream.
>>
>
> I see what you mean, Stream internally use endOfStream handling for
> implementing some of its protocol and must therefore know whether an
> endOfStream event will return nil or raise an Exception, is that it?

> On Mon, Jun 8, 2009 at 6:00 PM, Nicolas
> Cellier<[hidden email]> wrote:
>> 2009/6/8 Damien Cassou <[hidden email]>:
>>> On Sun, Jun 7, 2009 at 2:15 AM, Nicolas
>>> Cellier<[hidden email]> wrote:
>>>> Before adding a new set of messages, why not make the endOfStream pluggable?
>>>
>>> I'm not sure it will work because different methods will expect
>>> different behavior. Thus these methods won't be able to communicate
>>> with the same stream.
>>>
>>
>> I see what you mean, Stream internally use endOfStream handling for
>> implementing some of its protocol and must therefore know whether an
>> endOfStream event will return nil or raise an Exception, is that it?
>
> Yes
>
>
>> Messages that use construct like:
>>    [self atEnd] whileFalse: [...]
>> should always work.
>
> Yes
>
>> Messages that use constructs like:
>>    [(char := stream next) ~~ nil] whileTrue: [...]
>> could eventually be written:
>>    | oldEndOfStream |
>>    oldEndOfStream := endOfStream.
>>    [[(char := stream next) ~~ nil] whileTrue: [...]]
>>        ensure: [endOfStream := oldEndOfStream].
>
> better:
>
> stream do: [:char | ...]
>
> which is a good refactoring in all cases, even without the proposed
> changed I guess.
>

> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Lambdas are relegated to relative obscurity until Java makes them
> popular by not having them." James Iry
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>