Re: [Pharo-dev] Can anyone explain #asInteger for Strings?

[p...@highoctane.be]

On Fri, Jan 13, 2017 at 1:24 PM, Sven Van Caekenberghe  wrote:

>
> > On 13 Jan 2017, at 13:15, p...@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 
> 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 
> 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  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.
> > >
> > >
> >
> >
> >
>
>
>

Re: [Pharo-dev] Can anyone explain #asInteger for Strings?

[Sven Van Caekenberghe]

> On 13 Jan 2017, at 13:15, p...@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  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  
> > 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 
> >  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.
> >
> >
> 
> 
> 

Re: [Pharo-dev] Can anyone explain #asInteger for Strings?

[p...@highoctane.be]

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

Phil

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

Re: [Pharo-dev] Can anyone explain #asInteger for Strings?

[Sven Van Caekenberghe]

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  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 
>  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.
> 
> 

Re: [Pharo-dev] Can anyone explain #asInteger for Strings?

[Guillermo Polito]

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.sarg...@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.
>
>

[Pharo-dev] Can anyone explain #asInteger for Strings?

[Richard Sargent]

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.