[Pharo-project] 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
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
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
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
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
Before adding a new set of messages, why not make the endOfStream pluggable? I mean add an endOfStream inst. var. to Stream. Initialize it with something that can understand value and will answer nil to not break existing base ([] for instance, or nil->nil) Then use (^endOfStream value) where due. Provide some handy hooks like: Stream>>doSignalEndOfStream endOfStream := [EndOfStreamError raise]. Stream>>doNotifyEndOfStream endOfStream := [EndOfStreamNotification raise]. Nicolas 2009/6/7 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sun, Jun 7, 2009 at 2:15 AM, Nicolas Cellier<nicolas.cellier.aka.nice@gmail.com> 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. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
2009/6/8 Damien Cassou <damien.cassou@gmail.com>:
On Sun, Jun 7, 2009 at 2:15 AM, Nicolas Cellier<nicolas.cellier.aka.nice@gmail.com> 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? Messages that use construct like: [self atEnd] whileFalse: [...] should always work. 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]. Nicolas
-- 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, Jun 8, 2009 at 6:00 PM, Nicolas Cellier<nicolas.cellier.aka.nice@gmail.com> wrote:
2009/6/8 Damien Cassou <damien.cassou@gmail.com>:
On Sun, Jun 7, 2009 at 2:15 AM, Nicolas Cellier<nicolas.cellier.aka.nice@gmail.com> 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
2009/6/8 Damien Cassou <damien.cassou@gmail.com>:
On Mon, Jun 8, 2009 at 6:00 PM, Nicolas Cellier<nicolas.cellier.aka.nice@gmail.com> wrote:
2009/6/8 Damien Cassou <damien.cassou@gmail.com>:
On Sun, Jun 7, 2009 at 2:15 AM, Nicolas Cellier<nicolas.cellier.aka.nice@gmail.com> 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.
:) When I stay at the surface of existing code, you exercise your brain a bit deeper, and that's good. However, you also have to benchmark the different approaches on some critical kernel methods. I had animated discussions with Andreas on the subject! (see http://bugs.squeak.org/view.php?id=6755 ) Nicolas
-- 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Damien Cassou -
Nicolas Cellier -
Schwab,Wilhelm K -
Stéphane Ducasse