[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 < nicolas.cellier.aka.nice@gmail.com> 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 <johan@inceptive.be>:
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 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
2010/8/24 Guillermo Polito <guillermopolito@gmail.com>:
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 <nicolas.cellier.aka.nice@gmail.com> 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 <johan@inceptive.be>:
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 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
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 <nicolas.cellier.aka.nice@gmail.com> 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 <johan@inceptive.be>:
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 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
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 <stephane.ducasse@inria.fr
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 <nicolas.cellier.aka.nice@gmail.com> 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 <johan@inceptive.be>:
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 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
I submitted the fix (just removed the "failBlock:[^0]") and some new tests. Name: SLICE-Issue-2857-StringToNumberConversionImprovement-GuillermoPolito.1 Author: GuillermoPolito Time: 24 August 2010, 7:17:42 pm UUID: 53653896-47e9-4451-920f-b8db7198bd06 Ancestors: Dependencies: Kernel-GuillermoPolito.735, KernelTests-GuillermoPolito.280 Number>>readFrom: and Integer>>readFrom: fails when they have to. Improved tests for reading Numbers from Strings On Tue, Aug 24, 2010 at 5:54 PM, Guillermo Polito <guillermopolito@gmail.com
wrote:
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 < stephane.ducasse@inria.fr> 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 <nicolas.cellier.aka.nice@gmail.com> 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 <johan@inceptive.be>:
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 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
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 <stephane.ducasse@inria.fr> 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 <nicolas.cellier.aka.nice@gmail.com> 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 <johan@inceptive.be>:
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 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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 <johan@inceptive.be> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
2010/8/26 Johan Brichau <johan@inceptive.be>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Thu, Aug 26, 2010 at 10:32 AM, Johan Brichau <johan@inceptive.be> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <guillermopolito@gmail.com> wrote:
On Thu, Aug 26, 2010 at 10:32 AM, Johan Brichau <johan@inceptive.be> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/8/26 Guillermo Polito <guillermopolito@gmail.com>:
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 <guillermopolito@gmail.com> wrote:
On Thu, Aug 26, 2010 at 10:32 AM, Johan Brichau <johan@inceptive.be> 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 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
'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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Johan Brichau [johan@inceptive.be] Sent: Thursday, August 26, 2010 8:43 AM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <nicolas.cellier.aka.nice@gmail.com> 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 <johan@inceptive.be>:
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 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
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-BillSchw... 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Tuesday, August 24, 2010 4:33 PM To: Pharo-project@lists.gforge.inria.fr 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 <nicolas.cellier.aka.nice@gmail.com<mailto:nicolas.cellier.aka.nice@gmail.com>> 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 <johan@inceptive.be<mailto:johan@inceptive.be>>:
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 Pharo-project@lists.gforge.inria.fr<mailto: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<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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-BillSchw...
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Tuesday, August 24, 2010 4:33 PM To: Pharo-project@lists.gforge.inria.fr 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 <nicolas.cellier.aka.nice@gmail.com<mailto:nicolas.cellier.aka.nice@gmail.com>> 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 <johan@inceptive.be<mailto:johan@inceptive.be>>:
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 Pharo-project@lists.gforge.inria.fr<mailto: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<mailto: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
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bschwab@anest.ufl.edu] Sent: Wednesday, August 25, 2010 5:01 AM To: Pharo-project@lists.gforge.inria.fr 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-BillSchw... 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Tuesday, August 24, 2010 4:33 PM To: Pharo-project@lists.gforge.inria.fr 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 <nicolas.cellier.aka.nice@gmail.com<mailto:nicolas.cellier.aka.nice@gmail.com>> 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 <johan@inceptive.be<mailto:johan@inceptive.be>>:
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 Pharo-project@lists.gforge.inria.fr<mailto: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<mailto: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
+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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bschwab@anest.ufl.edu] Sent: Wednesday, August 25, 2010 5:01 AM To: Pharo-project@lists.gforge.inria.fr 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-BillSchw...
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Tuesday, August 24, 2010 4:33 PM To: Pharo-project@lists.gforge.inria.fr 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 <nicolas.cellier.aka.nice@gmail.com<mailto:nicolas.cellier.aka.nice@gmail.com>> 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 <johan@inceptive.be<mailto:johan@inceptive.be>>:
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 Pharo-project@lists.gforge.inria.fr<mailto: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<mailto: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 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Wednesday, August 25, 2010 12:44 PM To: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bschwab@anest.ufl.edu] Sent: Wednesday, August 25, 2010 5:01 AM To: Pharo-project@lists.gforge.inria.fr 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-BillSchw...
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Tuesday, August 24, 2010 4:33 PM To: Pharo-project@lists.gforge.inria.fr 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 <nicolas.cellier.aka.nice@gmail.com<mailto:nicolas.cellier.aka.nice@gmail.com>> 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 <johan@inceptive.be<mailto:johan@inceptive.be>>:
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 Pharo-project@lists.gforge.inria.fr<mailto: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<mailto: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
participants (5)
-
Guillermo Polito -
Johan Brichau -
Nicolas Cellier -
Schwab,Wilhelm K -
Stéphane Ducasse