String to Number conversion
Locked
 
|
http://code.google.com/p/pharo/issues/detail?id=2857
Which will be the impact in the system and other tools to throw an error when the conversion cannot take place? I think an error must be thrown, but should it be in Pharo 1.2 or in next version? On Tue, Aug 24, 2010 at 11:45 AM, Nicolas Cellier <[hidden email]> wrote: In squeak, (Integer readFromString: 'foo') ->Error _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: String to Number conversion
|
|
2010/8/24 Guillermo Polito <[hidden email]>:
> http://code.google.com/p/pharo/issues/detail?id=2857 > > Which will be the impact in the system and other tools to throw an error > when the conversion cannot take place? > I think an error must be thrown, but should it be in Pharo 1.2 or in next > version? > My opinion: the system will be more predictible and cleaner ;) Nicolas > On Tue, Aug 24, 2010 at 11:45 AM, Nicolas Cellier > <[hidden email]> wrote: >> >> In squeak, (Integer readFromString: 'foo') ->Error >> >> Use: >> - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, >> - (Integer readFrom: 'foo' ifFail: []), to get nil >> >> Though it is possible, I dislike anwsering nil, because it would mean >> a bunch of #readFrom: send should be protected by #ifNil: Blocks... >> 1) That's nonsense, readFrom:ifFail: already does the work. >> 2) you cripple the code with Error conditions and end up with >> unreadable C-looking like code >> (3 lines of Error condition crap for 1 line of underlying algorithm >> at every function call) >> 3) Exception handling can avoid long chains of ifFail: / ifNil: tests >> >> But that conversation already took place many times... >> >> I'd like the readFrom:ifFail: form to be generalized to other objects, >> with default behaviour raising an Error. What do you think ? >> >> Nicolas >> >> 2010/8/24 Johan Brichau <[hidden email]>: >> > >> > On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote: >> > >> >> I thought that readFromString: was raising an error and that >> >> guessNumber* was returning zero >> > >> > I thought that too. I even have application code that shows that this >> > used to return nil in some version of Pharo... >> > But: >> > >> > 'foo' asInteger = nil >> > Integer readFromString: 'foo' = 0 >> > 'foo' asNumber -> Error >> > >> > aargh :-( >> > >> > disclaimer: currently testing this in pharo1.1 >> > >> > Johan >> > _______________________________________________ >> > 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 |
Re: String to Number conversion
|
|
In reply to this post by Guillermo Polito
did you check because with niko scwarz during the sprint at lille we discussed about
squeezeNumberOutOfString: Stef On Aug 24, 2010, at 10:33 PM, Guillermo Polito wrote: > http://code.google.com/p/pharo/issues/detail?id=2857 > > Which will be the impact in the system and other tools to throw an error when the conversion cannot take place? > I think an error must be thrown, but should it be in Pharo 1.2 or in next version? > > On Tue, Aug 24, 2010 at 11:45 AM, Nicolas Cellier <[hidden email]> wrote: > In squeak, (Integer readFromString: 'foo') ->Error > > Use: > - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, > - (Integer readFrom: 'foo' ifFail: []), to get nil > > Though it is possible, I dislike anwsering nil, because it would mean > a bunch of #readFrom: send should be protected by #ifNil: Blocks... > 1) That's nonsense, readFrom:ifFail: already does the work. > 2) you cripple the code with Error conditions and end up with > unreadable C-looking like code > (3 lines of Error condition crap for 1 line of underlying algorithm > at every function call) > 3) Exception handling can avoid long chains of ifFail: / ifNil: tests > > But that conversation already took place many times... > > I'd like the readFrom:ifFail: form to be generalized to other objects, > with default behaviour raising an Error. What do you think ? > > Nicolas > > 2010/8/24 Johan Brichau <[hidden email]>: > > > > On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote: > > > >> I thought that readFromString: was raising an error and that guessNumber* was returning zero > > > > I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... > > But: > > > > 'foo' asInteger = nil > > Integer readFromString: 'foo' = 0 > > 'foo' asNumber -> Error > > > > aargh :-( > > > > disclaimer: currently testing this in pharo1.1 > > > > Johan > > _______________________________________________ > > 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 |
Re: String to Number conversion
|
|
In reply to this post by Nicolas Cellier
>> http://code.google.com/p/pharo/issues/detail?id=2857 >> >> Which will be the impact in the system and other tools to throw an error >> when the conversion cannot take place? >> I think an error must be thrown, but should it be in Pharo 1.2 or in next >> version? >> > > My opinion: the system will be more predictible and cleaner ;) Me too. Still this is strange because I'm sure we did that with niko and introduce squeeze..... So may be we integrated some older code on top. I remember that even our changes broke scriptloader itself and the update stream :) > Nicolas > >> On Tue, Aug 24, 2010 at 11:45 AM, Nicolas Cellier >> <[hidden email]> wrote: >>> >>> In squeak, (Integer readFromString: 'foo') ->Error >>> >>> Use: >>> - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, >>> - (Integer readFrom: 'foo' ifFail: []), to get nil >>> >>> Though it is possible, I dislike anwsering nil, because it would mean >>> a bunch of #readFrom: send should be protected by #ifNil: Blocks... >>> 1) That's nonsense, readFrom:ifFail: already does the work. >>> 2) you cripple the code with Error conditions and end up with >>> unreadable C-looking like code >>> (3 lines of Error condition crap for 1 line of underlying algorithm >>> at every function call) >>> 3) Exception handling can avoid long chains of ifFail: / ifNil: tests >>> >>> But that conversation already took place many times... >>> >>> I'd like the readFrom:ifFail: form to be generalized to other objects, >>> with default behaviour raising an Error. What do you think ? >>> >>> Nicolas >>> >>> 2010/8/24 Johan Brichau <[hidden email]>: >>>> >>>> On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote: >>>> >>>>> I thought that readFromString: was raising an error and that >>>>> guessNumber* was returning zero >>>> >>>> I thought that too. I even have application code that shows that this >>>> used to return nil in some version of Pharo... >>>> But: >>>> >>>> 'foo' asInteger = nil >>>> Integer readFromString: 'foo' = 0 >>>> 'foo' asNumber -> Error >>>> >>>> aargh :-( >>>> >>>> disclaimer: currently testing this in pharo1.1 >>>> >>>> Johan >>>> _______________________________________________ >>>> 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 |
Re: String to Number conversion
|
|
Searching in the mails:
<quote> self assert: '123blabla' squeezeOutNumber equals: 123. self assert: 'blabla123' squeezeOutNumber equals: 123. self assert: 'blabla12blabla' squeezeOutNumber equals: 12. self assert: ('12.3bla' squeezeOutNumber -12.3 ) abs < 0.0001. self assert: '.1' squeezeOutNumber > 0. </quote> I tried it in my image and 'bla' squeezeOutNumber. fails because of a primitive error... Anyway, the behavior is a little different from the existent in #readFrom: Did you mean to let the dirty stuff to #squeezeOutNumber and throw the error in the #readFrom:? On Tue, Aug 24, 2010 at 5:49 PM, Stéphane Ducasse <[hidden email]> wrote:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: String to Number conversion
|
|
I submitted the fix (just removed the "failBlock:[^0]") and some new tests.
Name: SLICE-Issue-2857-StringToNumberConversionImprovement-GuillermoPolito.1 On Tue, Aug 24, 2010 at 5:54 PM, Guillermo Polito <[hidden email]> wrote: Searching in the mails: _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: String to Number conversion
|
|
In reply to this post by Guillermo Polito
> Searching in the mails:
> > <quote> > self assert: '123blabla' squeezeOutNumber equals: 123. > self assert: 'blabla123' squeezeOutNumber equals: 123. > self assert: 'blabla12blabla' squeezeOutNumber equals: 12. > self assert: ('12.3bla' squeezeOutNumber -12.3 ) abs < 0.0001. > self assert: '.1' squeezeOutNumber > 0. > </quote> > > I tried it in my image and > 'bla' squeezeOutNumber. > fails because of a primitive error... Sounds really what we want :) after users can also do squeezeNumberOutOfString: stringOrStream onError: [0] > Anyway, the behavior is a little different from the existent in #readFrom: This is the key point > Did you mean to let the dirty stuff to #squeezeOutNumber and throw the error in the #readFrom:? Yes. Now we should identify user of readFrom: that in fact are expecting squeezeOutNumber and fix them. Stef > > On Tue, Aug 24, 2010 at 5:49 PM, Stéphane Ducasse <[hidden email]> wrote: > > >> http://code.google.com/p/pharo/issues/detail?id=2857 > >> > >> Which will be the impact in the system and other tools to throw an error > >> when the conversion cannot take place? > >> I think an error must be thrown, but should it be in Pharo 1.2 or in next > >> version? > >> > > > > My opinion: the system will be more predictible and cleaner ;) > > Me too. > Still this is strange because I'm sure we did that with niko and introduce squeeze..... > So may be we integrated some older code on top. > I remember that even our changes broke scriptloader itself and the update stream :) > > > Nicolas > > > >> On Tue, Aug 24, 2010 at 11:45 AM, Nicolas Cellier > >> <[hidden email]> wrote: > >>> > >>> In squeak, (Integer readFromString: 'foo') ->Error > >>> > >>> Use: > >>> - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, > >>> - (Integer readFrom: 'foo' ifFail: []), to get nil > >>> > >>> Though it is possible, I dislike anwsering nil, because it would mean > >>> a bunch of #readFrom: send should be protected by #ifNil: Blocks... > >>> 1) That's nonsense, readFrom:ifFail: already does the work. > >>> 2) you cripple the code with Error conditions and end up with > >>> unreadable C-looking like code > >>> (3 lines of Error condition crap for 1 line of underlying algorithm > >>> at every function call) > >>> 3) Exception handling can avoid long chains of ifFail: / ifNil: tests > >>> > >>> But that conversation already took place many times... > >>> > >>> I'd like the readFrom:ifFail: form to be generalized to other objects, > >>> with default behaviour raising an Error. What do you think ? > >>> > >>> Nicolas > >>> > >>> 2010/8/24 Johan Brichau <[hidden email]>: > >>>> > >>>> On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote: > >>>> > >>>>> I thought that readFromString: was raising an error and that > >>>>> guessNumber* was returning zero > >>>> > >>>> I thought that too. I even have application code that shows that this > >>>> used to return nil in some version of Pharo... > >>>> But: > >>>> > >>>> 'foo' asInteger = nil > >>>> Integer readFromString: 'foo' = 0 > >>>> 'foo' asNumber -> Error > >>>> > >>>> aargh :-( > >>>> > >>>> disclaimer: currently testing this in pharo1.1 > >>>> > >>>> Johan > >>>> _______________________________________________ > >>>> 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 > > _______________________________________________ > 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 |
Re: String to Number conversion
|
|
In reply to this post by Guillermo Polito
Squeak has a long tradition of silent failures of all types (in the image and the vm), and IMNSHO, it is a **really** bad idea with terrible consequences and needs to be fixed. Default actions that return nil merely push problems down stream to a point where there is no context to figure out what went wrong. I think much of this goes back to the late 70's and early 80's, before structured exception handling, and has never been modernized. Dolphin, which started life in the mid 90's, is built from the ground up to do these things correctly. Once one learns that the exceptions are indeed helping to make things work reliably, it is hard to imagine making something robust without them.
Exceptions can be expensive, both to set up handlers, and even more so when exceptions are thrown. You have identified the answer, which is to provide #readFrom:ifFail: (or #readFrom:onError: - whatever you want to call it) that evaluates a block when things go wrong, which allows one to bypass the overhead, much like #at:ifAbsent:; if error and remedy are near by, it is easy to do and skips the overhead. For the lazy<g>, or simply for frameworks that can/should use exceptions to handle exceptional conditions (big separation between the problem and anything that knows how to cope with it), #readFrom: (without the block) does the robust/correct thing, and raises an exception. As you no doubt know, it can (often should) be written in terms of #readFrom:ifFail: with the block raising the exception. Things will break for a while, but I hesitate to think how much stuff is just plain broken and we never notice it because things answer nil and/or ignore error conditions. The industry tried to formalize such head-in-the-sand-hope-it-goes-away design under the fancy name "defensive programming." It remains a useful approach when used sparingly to keep critical systems running, but it generally failed under its own lack of merit. It was popularized as a way to cope with the dreaded UAEs of 16 bit Windows, which was in turn due to the lack of exception handling and ensured execution in the GUI, which lead to incomplete cleanup, memory leaks, and all kinds of crashes. YES. PLEASE DO THIS. **GREAT** IDEA. You might take a look at http://www.squeaksource.com/PharoInbox/DolphinCompatibility-Streams-BillSchwab.1.mcz for what I consider to be very much related changes to stream I/O. Since it quickly became obvious to me that #next and #next: were not going to change any time soon, I simply stopped using them myself; instead I write code using #nextOne, #nextMany:, and #nextAvailable:. You will also find methods such as #nextDWORD to help with binary file formats, device interfacing, etc . It is a work in progress, but the idea is to have read streams bark when they run out of data, unless (#nextAvailable:) specifically authorized to truncate. I also have some text converters modeled after Dolphin's framework. I don't think I have released those yet, but plan to do so eventually. Because of the problem you have identified, I have added some tests (and throw exceptions when they fail) for whether the stream is or is not at the end or read an expected number of types, etc. Thanks for working on this! Bill ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Guillermo Polito [[hidden email]] Sent: Tuesday, August 24, 2010 4:33 PM To: [hidden email] Subject: [Pharo-project] String to Number conversion http://code.google.com/p/pharo/issues/detail?id=2857 Which will be the impact in the system and other tools to throw an error when the conversion cannot take place? I think an error must be thrown, but should it be in Pharo 1.2 or in next version? On Tue, Aug 24, 2010 at 11:45 AM, Nicolas Cellier <[hidden email]<mailto:[hidden email]>> wrote: In squeak, (Integer readFromString: 'foo') ->Error Use: - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, - (Integer readFrom: 'foo' ifFail: []), to get nil Though it is possible, I dislike anwsering nil, because it would mean a bunch of #readFrom: send should be protected by #ifNil: Blocks... 1) That's nonsense, readFrom:ifFail: already does the work. 2) you cripple the code with Error conditions and end up with unreadable C-looking like code (3 lines of Error condition crap for 1 line of underlying algorithm at every function call) 3) Exception handling can avoid long chains of ifFail: / ifNil: tests But that conversation already took place many times... I'd like the readFrom:ifFail: form to be generalized to other objects, with default behaviour raising an Error. What do you think ? Nicolas 2010/8/24 Johan Brichau <[hidden email]<mailto:[hidden email]>>: > > On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote: > >> I thought that readFromString: was raising an error and that guessNumber* was returning zero > > I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... > But: > > 'foo' asInteger = nil > Integer readFromString: 'foo' = 0 > 'foo' asNumber -> Error > > aargh :-( > > disclaimer: currently testing this in pharo1.1 > > Johan > _______________________________________________ > Pharo-project mailing list > [hidden email]<mailto:[hidden email]> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email]<mailto:[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 |
Re: String to Number conversion
|
|
Ok I will have to read it finally :)
Stef On Aug 25, 2010, at 11:01 AM, Schwab,Wilhelm K wrote: > Squeak has a long tradition of silent failures of all types (in the image and the vm), and IMNSHO, it is a **really** bad idea with terrible consequences and needs to be fixed. Default actions that return nil merely push problems down stream to a point where there is no context to figure out what went wrong. I think much of this goes back to the late 70's and early 80's, before structured exception handling, and has never been modernized. Dolphin, which started life in the mid 90's, is built from the ground up to do these things correctly. Once one learns that the exceptions are indeed helping to make things work reliably, it is hard to imagine making something robust without them. > > Exceptions can be expensive, both to set up handlers, and even more so when exceptions are thrown. You have identified the answer, which is to provide #readFrom:ifFail: (or #readFrom:onError: - whatever you want to call it) that evaluates a block when things go wrong, which allows one to bypass the overhead, much like #at:ifAbsent:; if error and remedy are near by, it is easy to do and skips the overhead. For the lazy<g>, or simply for frameworks that can/should use exceptions to handle exceptional conditions (big separation between the problem and anything that knows how to cope with it), #readFrom: (without the block) does the robust/correct thing, and raises an exception. As you no doubt know, it can (often should) be written in terms of #readFrom:ifFail: with the block raising the exception. > > Things will break for a while, but I hesitate to think how much stuff is just plain broken and we never notice it because things answer nil and/or ignore error conditions. The industry tried to formalize such head-in-the-sand-hope-it-goes-away design under the fancy name "defensive programming." It remains a useful approach when used sparingly to keep critical systems running, but it generally failed under its own lack of merit. It was popularized as a way to cope with the dreaded UAEs of 16 bit Windows, which was in turn due to the lack of exception handling and ensured execution in the GUI, which lead to incomplete cleanup, memory leaks, and all kinds of crashes. > > YES. PLEASE DO THIS. **GREAT** IDEA. You might take a look at > > http://www.squeaksource.com/PharoInbox/DolphinCompatibility-Streams-BillSchwab.1.mcz > > for what I consider to be very much related changes to stream I/O. Since it quickly became obvious to me that #next and #next: were not going to change any time soon, I simply stopped using them myself; instead I write code using #nextOne, #nextMany:, and #nextAvailable:. You will also find methods such as #nextDWORD to help with binary file formats, device interfacing, etc . > > It is a work in progress, but the idea is to have read streams bark when they run out of data, unless (#nextAvailable:) specifically authorized to truncate. I also have some text converters modeled after Dolphin's framework. I don't think I have released those yet, but plan to do so eventually. Because of the problem you have identified, I have added some tests (and throw exceptions when they fail) for whether the stream is or is not at the end or read an expected number of types, etc. > > Thanks for working on this! > > Bill > > > > ________________________________________ > From: [hidden email] [[hidden email]] On Behalf Of Guillermo Polito [[hidden email]] > Sent: Tuesday, August 24, 2010 4:33 PM > To: [hidden email] > Subject: [Pharo-project] String to Number conversion > > http://code.google.com/p/pharo/issues/detail?id=2857 > > Which will be the impact in the system and other tools to throw an error when the conversion cannot take place? > I think an error must be thrown, but should it be in Pharo 1.2 or in next version? > > On Tue, Aug 24, 2010 at 11:45 AM, Nicolas Cellier <[hidden email]<mailto:[hidden email]>> wrote: > In squeak, (Integer readFromString: 'foo') ->Error > > Use: > - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, > - (Integer readFrom: 'foo' ifFail: []), to get nil > > Though it is possible, I dislike anwsering nil, because it would mean > a bunch of #readFrom: send should be protected by #ifNil: Blocks... > 1) That's nonsense, readFrom:ifFail: already does the work. > 2) you cripple the code with Error conditions and end up with > unreadable C-looking like code > (3 lines of Error condition crap for 1 line of underlying algorithm > at every function call) > 3) Exception handling can avoid long chains of ifFail: / ifNil: tests > > But that conversation already took place many times... > > I'd like the readFrom:ifFail: form to be generalized to other objects, > with default behaviour raising an Error. What do you think ? > > Nicolas > > 2010/8/24 Johan Brichau <[hidden email]<mailto:[hidden email]>>: >> >> On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote: >> >>> I thought that readFromString: was raising an error and that guessNumber* was returning zero >> >> I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... >> But: >> >> 'foo' asInteger = nil >> Integer readFromString: 'foo' = 0 >> 'foo' asNumber -> Error >> >> aargh :-( >> >> disclaimer: currently testing this in pharo1.1 >> >> Johan >> _______________________________________________ >> Pharo-project mailing list >> [hidden email]<mailto:[hidden email]> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email]<mailto:[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 |
Re: String to Number conversion
|
|
In reply to this post by Schwab,Wilhelm K
While I'm on rant, what happened to the good old day when men were men and 2+'2' was not 4? I *still* have bugs in my R data frame code because of that nonsense - just tell me I blew it, please?? Ceorsing integers to floats to make things like 2+Float pi is a good thing, converting strings to numbers is coddling that ultimately backfires.
Bill ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Schwab,Wilhelm K [[hidden email]] Sent: Wednesday, August 25, 2010 5:01 AM To: [hidden email] Subject: Re: [Pharo-project] String to Number conversion Squeak has a long tradition of silent failures of all types (in the image and the vm), and IMNSHO, it is a **really** bad idea with terrible consequences and needs to be fixed. Default actions that return nil merely push problems down stream to a point where there is no context to figure out what went wrong. I think much of this goes back to the late 70's and early 80's, before structured exception handling, and has never been modernized. Dolphin, which started life in the mid 90's, is built from the ground up to do these things correctly. Once one learns that the exceptions are indeed helping to make things work reliably, it is hard to imagine making something robust without them. Exceptions can be expensive, both to set up handlers, and even more so when exceptions are thrown. You have identified the answer, which is to provide #readFrom:ifFail: (or #readFrom:onError: - whatever you want to call it) that evaluates a block when things go wrong, which allows one to bypass the overhead, much like #at:ifAbsent:; if error and remedy are near by, it is easy to do and skips the overhead. For the lazy<g>, or simply for frameworks that can/should use exceptions to handle exceptional conditions (big separation between the problem and anything that knows how to cope with it), #readFrom: (without the block) does the robust/correct thing, and raises an exception. As you no doubt know, it can (often should) be written in terms of #readFrom:ifFail: with the block raising the exception. Things will break for a while, but I hesitate to think how much stuff is just plain broken and we never notice it because things answer nil and/or ignore error conditions. The industry tried to formalize such head-in-the-sand-hope-it-goes-away design under the fancy name "defensive programming." It remains a useful approach when used sparingly to keep critical systems running, but it generally failed under its own lack of merit. It was popularized as a way to cope with the dreaded UAEs of 16 bit Windows, which was in turn due to the lack of exception handling and ensured execution in the GUI, which lead to incomplete cleanup, memory leaks, and all kinds of crashes. YES. PLEASE DO THIS. **GREAT** IDEA. You might take a look at http://www.squeaksource.com/PharoInbox/DolphinCompatibility-Streams-BillSchwab.1.mcz for what I consider to be very much related changes to stream I/O. Since it quickly became obvious to me that #next and #next: were not going to change any time soon, I simply stopped using them myself; instead I write code using #nextOne, #nextMany:, and #nextAvailable:. You will also find methods such as #nextDWORD to help with binary file formats, device interfacing, etc . It is a work in progress, but the idea is to have read streams bark when they run out of data, unless (#nextAvailable:) specifically authorized to truncate. I also have some text converters modeled after Dolphin's framework. I don't think I have released those yet, but plan to do so eventually. Because of the problem you have identified, I have added some tests (and throw exceptions when they fail) for whether the stream is or is not at the end or read an expected number of types, etc. Thanks for working on this! Bill ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Guillermo Polito [[hidden email]] Sent: Tuesday, August 24, 2010 4:33 PM To: [hidden email] Subject: [Pharo-project] String to Number conversion http://code.google.com/p/pharo/issues/detail?id=2857 Which will be the impact in the system and other tools to throw an error when the conversion cannot take place? I think an error must be thrown, but should it be in Pharo 1.2 or in next version? On Tue, Aug 24, 2010 at 11:45 AM, Nicolas Cellier <[hidden email]<mailto:[hidden email]>> wrote: In squeak, (Integer readFromString: 'foo') ->Error Use: - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, - (Integer readFrom: 'foo' ifFail: []), to get nil Though it is possible, I dislike anwsering nil, because it would mean a bunch of #readFrom: send should be protected by #ifNil: Blocks... 1) That's nonsense, readFrom:ifFail: already does the work. 2) you cripple the code with Error conditions and end up with unreadable C-looking like code (3 lines of Error condition crap for 1 line of underlying algorithm at every function call) 3) Exception handling can avoid long chains of ifFail: / ifNil: tests But that conversation already took place many times... I'd like the readFrom:ifFail: form to be generalized to other objects, with default behaviour raising an Error. What do you think ? Nicolas 2010/8/24 Johan Brichau <[hidden email]<mailto:[hidden email]>>: > > On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote: > >> I thought that readFromString: was raising an error and that guessNumber* was returning zero > > I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... > But: > > 'foo' asInteger = nil > Integer readFromString: 'foo' = 0 > 'foo' asNumber -> Error > > aargh :-( > > disclaimer: currently testing this in pharo1.1 > > Johan > _______________________________________________ > Pharo-project mailing list > [hidden email]<mailto:[hidden email]> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email]<mailto:[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 |
Re: String to Number conversion
|
|
+1
Stef On Aug 25, 2010, at 12:53 PM, Schwab,Wilhelm K wrote: > While I'm on rant, what happened to the good old day when men were men and 2+'2' was not 4? I *still* have bugs in my R data frame code because of that nonsense - just tell me I blew it, please?? Ceorsing integers to floats to make things like 2+Float pi is a good thing, converting strings to numbers is coddling that ultimately backfires. > > Bill > > > > > ________________________________________ > From: [hidden email] [[hidden email]] On Behalf Of Schwab,Wilhelm K [[hidden email]] > Sent: Wednesday, August 25, 2010 5:01 AM > To: [hidden email] > Subject: Re: [Pharo-project] String to Number conversion > > Squeak has a long tradition of silent failures of all types (in the image and the vm), and IMNSHO, it is a **really** bad idea with terrible consequences and needs to be fixed. Default actions that return nil merely push problems down stream to a point where there is no context to figure out what went wrong. I think much of this goes back to the late 70's and early 80's, before structured exception handling, and has never been modernized. Dolphin, which started life in the mid 90's, is built from the ground up to do these things correctly. Once one learns that the exceptions are indeed helping to make things work reliably, it is hard to imagine making something robust without them. > > Exceptions can be expensive, both to set up handlers, and even more so when exceptions are thrown. You have identified the answer, which is to provide #readFrom:ifFail: (or #readFrom:onError: - whatever you want to call it) that evaluates a block when things go wrong, which allows one to bypass the overhead, much like #at:ifAbsent:; if error and remedy are near by, it is easy to do and skips the overhead. For the lazy<g>, or simply for frameworks that can/should use exceptions to handle exceptional conditions (big separation between the problem and anything that knows how to cope with it), #readFrom: (without the block) does the robust/correct thing, and raises an exception. As you no doubt know, it can (often should) be written in terms of #readFrom:ifFail: with the block raising the exception. > > Things will break for a while, but I hesitate to think how much stuff is just plain broken and we never notice it because things answer nil and/or ignore error conditions. The industry tried to formalize such head-in-the-sand-hope-it-goes-away design under the fancy name "defensive programming." It remains a useful approach when used sparingly to keep critical systems running, but it generally failed under its own lack of merit. It was popularized as a way to cope with the dreaded UAEs of 16 bit Windows, which was in turn due to the lack of exception handling and ensured execution in the GUI, which lead to incomplete cleanup, memory leaks, and all kinds of crashes. > > YES. PLEASE DO THIS. **GREAT** IDEA. You might take a look at > > http://www.squeaksource.com/PharoInbox/DolphinCompatibility-Streams-BillSchwab.1.mcz > > for what I consider to be very much related changes to stream I/O. Since it quickly became obvious to me that #next and #next: were not going to change any time soon, I simply stopped using them myself; instead I write code using #nextOne, #nextMany:, and #nextAvailable:. You will also find methods such as #nextDWORD to help with binary file formats, device interfacing, etc . > > It is a work in progress, but the idea is to have read streams bark when they run out of data, unless (#nextAvailable:) specifically authorized to truncate. I also have some text converters modeled after Dolphin's framework. I don't think I have released those yet, but plan to do so eventually. Because of the problem you have identified, I have added some tests (and throw exceptions when they fail) for whether the stream is or is not at the end or read an expected number of types, etc. > > Thanks for working on this! > > Bill > > > > ________________________________________ > From: [hidden email] [[hidden email]] On Behalf Of Guillermo Polito [[hidden email]] > Sent: Tuesday, August 24, 2010 4:33 PM > To: [hidden email] > Subject: [Pharo-project] String to Number conversion > > http://code.google.com/p/pharo/issues/detail?id=2857 > > Which will be the impact in the system and other tools to throw an error when the conversion cannot take place? > I think an error must be thrown, but should it be in Pharo 1.2 or in next version? > > On Tue, Aug 24, 2010 at 11:45 AM, Nicolas Cellier <[hidden email]<mailto:[hidden email]>> wrote: > In squeak, (Integer readFromString: 'foo') ->Error > > Use: > - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, > - (Integer readFrom: 'foo' ifFail: []), to get nil > > Though it is possible, I dislike anwsering nil, because it would mean > a bunch of #readFrom: send should be protected by #ifNil: Blocks... > 1) That's nonsense, readFrom:ifFail: already does the work. > 2) you cripple the code with Error conditions and end up with > unreadable C-looking like code > (3 lines of Error condition crap for 1 line of underlying algorithm > at every function call) > 3) Exception handling can avoid long chains of ifFail: / ifNil: tests > > But that conversation already took place many times... > > I'd like the readFrom:ifFail: form to be generalized to other objects, > with default behaviour raising an Error. What do you think ? > > Nicolas > > 2010/8/24 Johan Brichau <[hidden email]<mailto:[hidden email]>>: >> >> On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote: >> >>> I thought that readFromString: was raising an error and that guessNumber* was returning zero >> >> I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... >> But: >> >> 'foo' asInteger = nil >> Integer readFromString: 'foo' = 0 >> 'foo' asNumber -> Error >> >> aargh :-( >> >> disclaimer: currently testing this in pharo1.1 >> >> Johan >> _______________________________________________ >> Pharo-project mailing list >> [hidden email]<mailto:[hidden email]> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email]<mailto:[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 |
Re: String to Number conversion
|
|
Stef,
I thought about this a little more: perhaps the conversion got started for eToys? I could see somebody adding that to make them work; the Dolphin guy in me then screams Value-Adapter!!! :) A quick look at my image does not reveal an aspect value adapter and a converter; I thought I had built them. I probably did and lost track of them due to my (for far too long) woefully incomplete understanding of package info and MC. The basic idea is that a suitable object can be "clipped" between a thing that understands #value and #value: and a consumer. With some artful use, a text editor can then be used, for example, to edit a floating point aspect of something else. Having real closures vs. Smalltalk-80 blocks will only make it easier to get it right. I will look for an existing implementation of mine or put it in the queue; we can't not have these things. Bill ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Stéphane Ducasse [[hidden email]] Sent: Wednesday, August 25, 2010 12:44 PM To: [hidden email] Subject: Re: [Pharo-project] String to Number conversion +1 Stef On Aug 25, 2010, at 12:53 PM, Schwab,Wilhelm K wrote: > While I'm on rant, what happened to the good old day when men were men and 2+'2' was not 4? I *still* have bugs in my R data frame code because of that nonsense - just tell me I blew it, please?? Ceorsing integers to floats to make things like 2+Float pi is a good thing, converting strings to numbers is coddling that ultimately backfires. > > Bill > > > > > ________________________________________ > From: [hidden email] [[hidden email]] On Behalf Of Schwab,Wilhelm K [[hidden email]] > Sent: Wednesday, August 25, 2010 5:01 AM > To: [hidden email] > Subject: Re: [Pharo-project] String to Number conversion > > Squeak has a long tradition of silent failures of all types (in the image and the vm), and IMNSHO, it is a **really** bad idea with terrible consequences and needs to be fixed. Default actions that return nil merely push problems down stream to a point where there is no context to figure out what went wrong. I think much of this goes back to the late 70's and early 80's, before structured exception handling, and has never been modernized. Dolphin, which started life in the mid 90's, is built from the ground up to do these things correctly. Once one learns that the exceptions are indeed helping to make things work reliably, it is hard to imagine making something robust without them. > > Exceptions can be expensive, both to set up handlers, and even more so when exceptions are thrown. You have identified the answer, which is to provide #readFrom:ifFail: (or #readFrom:onError: - whatever you want to call it) that evaluates a block when things go wrong, which allows one to bypass the overhead, much like #at:ifAbsent:; if error and remedy are near by, it is easy to do and skips the overhead. For the lazy<g>, or simply for frameworks that can/should use exceptions to handle exceptional conditions (big separation between the problem and anything that knows how to cope with it), #readFrom: (without the block) does the robust/correct thing, and raises an exception. As you no doubt know, it can (often should) be written in terms of #readFrom:ifFail: with the block raising the exception. > > Things will break for a while, but I hesitate to think how much stuff is just plain broken and we never notice it because things answer nil and/or ignore error conditions. The industry tried to formalize such head-in-the-sand-hope-it-goes-away design under the fancy name "defensive programming." It remains a useful approach when used sparingly to keep critical systems running, but it generally failed under its own lack of merit. It was popularized as a way to cope with the dreaded UAEs of 16 bit Windows, which was in turn due to the lack of exception handling and ensured execution in the GUI, which lead to incomplete cleanup, memory leaks, and all kinds of crashes. > > YES. PLEASE DO THIS. **GREAT** IDEA. You might take a look at > > http://www.squeaksource.com/PharoInbox/DolphinCompatibility-Streams-BillSchwab.1.mcz > > for what I consider to be very much related changes to stream I/O. Since it quickly became obvious to me that #next and #next: were not going to change any time soon, I simply stopped using them myself; instead I write code using #nextOne, #nextMany:, and #nextAvailable:. You will also find methods such as #nextDWORD to help with binary file formats, device interfacing, etc . > > It is a work in progress, but the idea is to have read streams bark when they run out of data, unless (#nextAvailable:) specifically authorized to truncate. I also have some text converters modeled after Dolphin's framework. I don't think I have released those yet, but plan to do so eventually. Because of the problem you have identified, I have added some tests (and throw exceptions when they fail) for whether the stream is or is not at the end or read an expected number of types, etc. > > Thanks for working on this! > > Bill > > > > ________________________________________ > From: [hidden email] [[hidden email]] On Behalf Of Guillermo Polito [[hidden email]] > Sent: Tuesday, August 24, 2010 4:33 PM > To: [hidden email] > Subject: [Pharo-project] String to Number conversion > > http://code.google.com/p/pharo/issues/detail?id=2857 > > Which will be the impact in the system and other tools to throw an error when the conversion cannot take place? > I think an error must be thrown, but should it be in Pharo 1.2 or in next version? > > On Tue, Aug 24, 2010 at 11:45 AM, Nicolas Cellier <[hidden email]<mailto:[hidden email]>> wrote: > In squeak, (Integer readFromString: 'foo') ->Error > > Use: > - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, > - (Integer readFrom: 'foo' ifFail: []), to get nil > > Though it is possible, I dislike anwsering nil, because it would mean > a bunch of #readFrom: send should be protected by #ifNil: Blocks... > 1) That's nonsense, readFrom:ifFail: already does the work. > 2) you cripple the code with Error conditions and end up with > unreadable C-looking like code > (3 lines of Error condition crap for 1 line of underlying algorithm > at every function call) > 3) Exception handling can avoid long chains of ifFail: / ifNil: tests > > But that conversation already took place many times... > > I'd like the readFrom:ifFail: form to be generalized to other objects, > with default behaviour raising an Error. What do you think ? > > Nicolas > > 2010/8/24 Johan Brichau <[hidden email]<mailto:[hidden email]>>: >> >> On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote: >> >>> I thought that readFromString: was raising an error and that guessNumber* was returning zero >> >> I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... >> But: >> >> 'foo' asInteger = nil >> Integer readFromString: 'foo' = 0 >> 'foo' asNumber -> Error >> >> aargh :-( >> >> disclaimer: currently testing this in pharo1.1 >> >> Johan >> _______________________________________________ >> Pharo-project mailing list >> [hidden email]<mailto:[hidden email]> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email]<mailto:[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 |
Re: String to Number conversion
|
|
In reply to this post by Stéphane Ducasse
On 25 Aug 2010, at 09:26, Stéphane Ducasse wrote: >> Did you mean to let the dirty stuff to #squeezeOutNumber and throw the error in the #readFrom:? > > Yes. Now we should identify user of readFrom: that in fact are expecting squeezeOutNumber and fix them. Well, it seems that the current readFrom: only requires the string to _start_ with a valid format. This means that: '3foo' asInteger = 3 Should we not fail here too? What are the opinions? Johan _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: String to Number conversion
|
|
If you do:
Number readFrom: '3foo'. --> exception Number readFrom: '3foo' readStream --> 3 String#asNumber is defined as ^Number readFromString: self And #readFromString: does the readStream. They are two different things. What Integer>>readFrom: does and what String>>asNumber does. String>>asNumber should fail :). On Thu, Aug 26, 2010 at 9:43 AM, Johan Brichau <[hidden email]> wrote: > > On 25 Aug 2010, at 09:26, Stéphane Ducasse wrote: > >>> Did you mean to let the dirty stuff to #squeezeOutNumber and throw the error in the #readFrom:? >> >> Yes. Now we should identify user of readFrom: that in fact are expecting squeezeOutNumber and fix them. > > Well, it seems that the current readFrom: only requires the string to _start_ with a valid format. This means that: > > '3foo' asInteger = 3 > > Should we not fail here too? What are the opinions? > > Johan > _______________________________________________ > 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 |
Re: String to Number conversion
|
|
On 26 Aug 2010, at 15:09, Guillermo Polito wrote: > Number readFrom: '3foo'. --> exception > Number readFrom: '3foo' readStream --> 3 They both return 3 in my image. The comment of #readFrom: also says so that that is the expected behavior. But I'm not sure this is what we want. > String>>asNumber should fail :). agreed. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: String to Number conversion
|
|
2010/8/26 Johan Brichau <[hidden email]>:
> > On 26 Aug 2010, at 15:09, Guillermo Polito wrote: > >> Number readFrom: '3foo'. --> exception >> Number readFrom: '3foo' readStream --> 3 > > They both return 3 in my image. > The comment of #readFrom: also says so that that is the expected behavior. But I'm not sure this is what we want. > >> String>>asNumber should fail :). > > agreed. me too, that's what I suggested in another mail. Nicolas > _______________________________________________ > 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 |
Re: String to Number conversion
|
|
In reply to this post by Johan Brichau-2
'3foo' asInteger probably should fail, because there is no stream to be tested for #atEnd. Reading '3foo' from a stream *probably* should be ok by default, becauuse the stream will clearly not be a the end, one could easily want to read integers out of formatted strings.
________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Johan Brichau [[hidden email]] Sent: Thursday, August 26, 2010 8:43 AM To: [hidden email] Subject: Re: [Pharo-project] String to Number conversion On 25 Aug 2010, at 09:26, Stéphane Ducasse wrote: >> Did you mean to let the dirty stuff to #squeezeOutNumber and throw the error in the #readFrom:? > > Yes. Now we should identify user of readFrom: that in fact are expecting squeezeOutNumber and fix them. Well, it seems that the current readFrom: only requires the string to _start_ with a valid format. This means that: '3foo' asInteger = 3 Should we not fail here too? What are the opinions? Johan _______________________________________________ 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 |
Re: String to Number conversion
|
|
In reply to this post by Johan Brichau-2
On Thu, Aug 26, 2010 at 10:32 AM, Johan Brichau <[hidden email]> wrote:
> > On 26 Aug 2010, at 15:09, Guillermo Polito wrote: > >> Number readFrom: '3foo'. --> exception >> Number readFrom: '3foo' readStream --> 3 > > They both return 3 in my image. > The comment of #readFrom: also says so that that is the expected behavior. But I'm not sure this is what we want. > Yes, you're right. I meant 'foo3' :(. >> String>>asNumber should fail :). > > agreed. > _______________________________________________ > 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 |
Re: String to Number conversion
|
|
Maybe the parser should have a #readXXX for each #nextXXX. And let
the #readXXX check the for the end of the stream. On Thu, Aug 26, 2010 at 11:43 AM, Guillermo Polito <[hidden email]> wrote: > On Thu, Aug 26, 2010 at 10:32 AM, Johan Brichau <[hidden email]> wrote: >> >> On 26 Aug 2010, at 15:09, Guillermo Polito wrote: >> >>> Number readFrom: '3foo'. --> exception >>> Number readFrom: '3foo' readStream --> 3 >> >> They both return 3 in my image. >> The comment of #readFrom: also says so that that is the expected behavior. But I'm not sure this is what we want. >> > > Yes, you're right. I meant 'foo3' :(. > >>> String>>asNumber should fail :). >> >> agreed. >> _______________________________________________ >> 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 |
Re: String to Number conversion
|
|
2010/8/26 Guillermo Polito <[hidden email]>:
> Maybe the parser should have a #readXXX for each #nextXXX. And let > the #readXXX check the for the end of the stream. > yes, that the idea, something like readFrom: aStream ifFail: aBlock | result | result := nextFrom: aStream ifFail: [^aBlock value]. (aStream skipSeparators; atEnd) ifFalse: [self error: 'nothing more expected']. ^result Nicolas > On Thu, Aug 26, 2010 at 11:43 AM, Guillermo Polito > <[hidden email]> wrote: >> On Thu, Aug 26, 2010 at 10:32 AM, Johan Brichau <[hidden email]> wrote: >>> >>> On 26 Aug 2010, at 15:09, Guillermo Polito wrote: >>> >>>> Number readFrom: '3foo'. --> exception >>>> Number readFrom: '3foo' readStream --> 3 >>> >>> They both return 3 in my image. >>> The comment of #readFrom: also says so that that is the expected behavior. But I'm not sure this is what we want. >>> >> >> Yes, you're right. I meant 'foo3' :(. >> >>>> String>>asNumber should fail :). >>> >>> agreed. >>> _______________________________________________ >>> 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 |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |