Smalltalk › Pharo › Pharo Smalltalk Developers

Can anyone explain #asInteger for Strings?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Richard Sargent

Can anyone explain #asInteger for Strings?

Administrator

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

Guillermo Polito

Re: Can anyone explain #asInteger for Strings?

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 <[hidden email]> 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.

Sven Van Caekenberghe-2

Re: Can anyone explain #asInteger for Strings?

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 <[hidden email]> 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 <[hidden email]> 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.
>
>

philippeback

Re: Can anyone explain #asInteger for Strings?

I guess Number class readFrom: stringOrStream is more up to date.

Phil

On Fri, Jan 13, 2017 at 11:02 AM, Sven Van Caekenberghe <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.
>
>

Sven Van Caekenberghe-2

Re: Can anyone explain #asInteger for Strings?

> On 13 Jan 2017, at 13:15, [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.
> >
> >
>
>
>

philippeback

Re: Can anyone explain #asInteger for Strings?

On Fri, Jan 13, 2017 at 1:24 PM, Sven Van Caekenberghe <[hidden email]> wrote:

> On 13 Jan 2017, at 13:15, [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.
> >
> >
>
>
>