Can anyone explain #asInteger for Strings?
I've come across an implementation of #asInteger and #asSignedInteger in Pharo 3.0 that leaves me scratching my head. Can anyone explain why it was defined to answer what it does for strings that one would really not expect to parse as a number. 'abc-123-xyz-897' asSignedInteger ===> -123 To my mind, the method that does this for the example string should have an intention revealing name like #spelunkIntegerFromString or some such. Thanks, Richard -- View this message in context: http://forum.world.st/Can-anyone-explain-asInteger-for-Strings-tp4929502.htm... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Ugly. And old, really old. I remember at one point in time there was a "squeezeNumberOutOfString" or something like that. Now, I'd like to fix this, because it just introduces noise and probably a lot of strange code. But the problem is not fixing it on itself, but checking all possible users relying on such strange behaviour. I bet that fixing it naively could lead to break your image :). On Fri, Jan 13, 2017 at 4:05 AM, Richard Sargent < richard.sargent@gemtalksystems.com> wrote:
I've come across an implementation of #asInteger and #asSignedInteger in Pharo 3.0 that leaves me scratching my head.
Can anyone explain why it was defined to answer what it does for strings that one would really not expect to parse as a number.
'abc-123-xyz-897' asSignedInteger ===> -123
To my mind, the method that does this for the example string should have an intention revealing name like #spelunkIntegerFromString or some such.
Thanks, Richard
-- View this message in context: http://forum.world.st/Can- anyone-explain-asInteger-for-Strings-tp4929502.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Yes it is legacy, yes changing it will break things. Now, this is not such an easy topic. I agree that the example given goes way too far (as a general parser), but most parsers will allow junk at the end, as in '100euro'. Often good, sometimes bad. So it depends on the use case. Strict vs lenient. Also, let's not add more methods to String, please.
On 13 Jan 2017, at 10:51, Guillermo Polito <guillermopolito@gmail.com> wrote:
Ugly. And old, really old. I remember at one point in time there was a "squeezeNumberOutOfString" or something like that.
Now, I'd like to fix this, because it just introduces noise and probably a lot of strange code. But the problem is not fixing it on itself, but checking all possible users relying on such strange behaviour. I bet that fixing it naively could lead to break your image :).
On Fri, Jan 13, 2017 at 4:05 AM, Richard Sargent <richard.sargent@gemtalksystems.com> wrote: I've come across an implementation of #asInteger and #asSignedInteger in Pharo 3.0 that leaves me scratching my head.
Can anyone explain why it was defined to answer what it does for strings that one would really not expect to parse as a number.
'abc-123-xyz-897' asSignedInteger ===> -123
To my mind, the method that does this for the example string should have an intention revealing name like #spelunkIntegerFromString or some such.
Thanks, Richard
-- View this message in context: http://forum.world.st/Can-anyone-explain-asInteger-for-Strings-tp4929502.htm... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I guess Number class readFrom: stringOrStream is more up to date. Phil On Fri, Jan 13, 2017 at 11:02 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Yes it is legacy, yes changing it will break things.
Now, this is not such an easy topic. I agree that the example given goes way too far (as a general parser), but most parsers will allow junk at the end, as in '100euro'. Often good, sometimes bad. So it depends on the use case. Strict vs lenient.
Also, let's not add more methods to String, please.
On 13 Jan 2017, at 10:51, Guillermo Polito <guillermopolito@gmail.com> wrote:
Ugly. And old, really old. I remember at one point in time there was a "squeezeNumberOutOfString" or something like that.
Now, I'd like to fix this, because it just introduces noise and probably a lot of strange code. But the problem is not fixing it on itself, but checking all possible users relying on such strange behaviour. I bet that fixing it naively could lead to break your image :).
On Fri, Jan 13, 2017 at 4:05 AM, Richard Sargent <richard.sargent@ gemtalksystems.com> wrote: I've come across an implementation of #asInteger and #asSignedInteger in Pharo 3.0 that leaves me scratching my head.
Can anyone explain why it was defined to answer what it does for strings that one would really not expect to parse as a number.
'abc-123-xyz-897' asSignedInteger ===> -123
To my mind, the method that does this for the example string should have an intention revealing name like #spelunkIntegerFromString or some such.
Thanks, Richard
-- View this message in context: http://forum.world.st/Can- anyone-explain-asInteger-for-Strings-tp4929502.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 13 Jan 2017, at 13:15, phil@highoctane.be wrote:
I guess Number class readFrom: stringOrStream is more up to date.
But it still allows junk at the end, that may or may not be what you want (e.g. if you want to validate an input field).
Phil
On Fri, Jan 13, 2017 at 11:02 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote: Yes it is legacy, yes changing it will break things.
Now, this is not such an easy topic. I agree that the example given goes way too far (as a general parser), but most parsers will allow junk at the end, as in '100euro'. Often good, sometimes bad. So it depends on the use case. Strict vs lenient.
Also, let's not add more methods to String, please.
On 13 Jan 2017, at 10:51, Guillermo Polito <guillermopolito@gmail.com> wrote:
Ugly. And old, really old. I remember at one point in time there was a "squeezeNumberOutOfString" or something like that.
Now, I'd like to fix this, because it just introduces noise and probably a lot of strange code. But the problem is not fixing it on itself, but checking all possible users relying on such strange behaviour. I bet that fixing it naively could lead to break your image :).
On Fri, Jan 13, 2017 at 4:05 AM, Richard Sargent <richard.sargent@gemtalksystems.com> wrote: I've come across an implementation of #asInteger and #asSignedInteger in Pharo 3.0 that leaves me scratching my head.
Can anyone explain why it was defined to answer what it does for strings that one would really not expect to parse as a number.
'abc-123-xyz-897' asSignedInteger ===> -123
To my mind, the method that does this for the example string should have an intention revealing name like #spelunkIntegerFromString or some such.
Thanks, Richard
-- View this message in context: http://forum.world.st/Can-anyone-explain-asInteger-for-Strings-tp4929502.htm... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Fri, Jan 13, 2017 at 1:24 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Jan 2017, at 13:15, phil@highoctane.be wrote:
I guess Number class readFrom: stringOrStream is more up to date.
But it still allows junk at the end, that may or may not be what you want (e.g. if you want to validate an input field).
Then I'd do something like this: input := '123'. regex := '^[0-9]{3,7}$'. (input matchesRegex: regex) ifTrue: [ Number readFrom: input ] ifFalse: [ nil ] where regex is adjusted for what I need (number of digits etc). http://www.regextester.com/21 Phil
Phil
On Fri, Jan 13, 2017 at 11:02 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote: Yes it is legacy, yes changing it will break things.
Now, this is not such an easy topic. I agree that the example given goes way too far (as a general parser), but most parsers will allow junk at the end, as in '100euro'. Often good, sometimes bad. So it depends on the use case. Strict vs lenient.
Also, let's not add more methods to String, please.
On 13 Jan 2017, at 10:51, Guillermo Polito <guillermopolito@gmail.com> wrote:
Ugly. And old, really old. I remember at one point in time there was a "squeezeNumberOutOfString" or something like that.
Now, I'd like to fix this, because it just introduces noise and probably a lot of strange code. But the problem is not fixing it on itself, but checking all possible users relying on such strange behaviour. I bet that fixing it naively could lead to break your image :).
On Fri, Jan 13, 2017 at 4:05 AM, Richard Sargent <richard.sargent@ gemtalksystems.com> wrote: I've come across an implementation of #asInteger and #asSignedInteger in Pharo 3.0 that leaves me scratching my head.
Can anyone explain why it was defined to answer what it does for strings that one would really not expect to parse as a number.
'abc-123-xyz-897' asSignedInteger ===> -123
To my mind, the method that does this for the example string should have an intention revealing name like #spelunkIntegerFromString or some such.
Thanks, Richard
-- View this message in context: http://forum.world.st/Can- anyone-explain-asInteger-for-Strings-tp4929502.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (4)
-
Guillermo Polito -
phil＠highoctane.be -
Richard Sargent -
Sven Van Caekenberghe