#String -> #asInteger from EsLoggingFramework

[Klaus Breker]

Hello,

yesterdayy I had a liitle problem with our application, because VA Smalltalk with the Logging Framework extends #String with #asInteger. We have an old method which extends #EsString with #asInteger. The behaviour of the logging framework extension of #asInteger returns immedialtly 0 when the first character of the string is not a number.

Then '  33' asInteger returns 0. In Pharo this evaluates to 33, in our application too.

What is now the right behaviour?

Regards

Klaus

[Marten Feldtmann]

This method only calls EsString>>asNumber. And VisualWorks removes any leading seperators before conversion is done.

[Klaus Breker]

Hi Marten,

then VA Smalltalk is the exception. #EsString -> #asNumber doesn't removes any leading separators.

asNumber

    "Answer the object conforming to integer specified by the
     receiver."

    | result selfSize negative |
    result := 0.
    (selfSize := self size) == 0 ifTrue: [^result].
    [:char |
        char isDigit ifFalse: [
            negative ifTrue: [^result negated].
            ^result
        ].
        result := result * 10 + char digitValue.
    ] apply: self from: ((negative := (self at: 1) == $-) ifTrue: [2] ifFalse: [1]) to: selfSize.
    negative ifTrue: [^result negated].
    ^result

[John O'Keefe]

Klaus -

 

Conversion of a string to a number (be it a float, a fraction, a scaled decimal, or an integer) is not covered by the ANSI Standard (which is too bad). It means that each platform can define the semantics of #asInteger.  So, strictly speaking, neither Pharo/Squeak/VW nor VA Smalltalk is wrong -- they are simply different.

 

Having said that, the fact that #asInteger is implemented in only 2 sort of out of the way places in VA Smalltalk gives us some flexibility to change it if it seems that it should behave differently than #asNumber. It is probably worthwhile to note that #asNumber (which has been around in VA Smalltalk forever with its current implementation) is poorly named since one might expect it to parse out any kind of number from a string, not just integers.

 

So, we can change #asInteger if there is a good reason to change it.  The fact that it behaves differently than Pharo/Squeak/VW is a reason, but not a good enough reason (just my opinion).  So give me some more reasons and see if you can convince me to change it.

 

John

[jtu...@objektfabrik.de]

I tend to be sceptical about a change. 

It is questionable if ' 33' is a number or an Integer, but if I as a developer want to make sure it is interpreted as one, I can always do a trimBlanks before I send #asInteger. There is a lot of space for interpretation in the whole area of String to number conversion and it is somewhat hard to draw a line. Should '.56' asInteger  be 0 or 1? Or should it throw an exception? Should '' asInteger answer 0 or throw an exception? And what about ' ' or 'x'?

The danger of breaking a lot of exiting code with a small change that is not a correction per se (the results will always be debatable) is quite high.

VW and especially Squeak and Pharo provide many methods that make life easier in many situations, but are misleading or incorrect in others.

Just a thought

Joachim

[Marten Feldtmann]

On the other hand it is even more questionable, that such a general method "asInteger" (without prefix) is introduced by a logging framework and not by a general library.

Concerning the name of #asNumber. That can not be changed any more. Perhaps it would be better to introduce a

#asNumber:locale:

then the programmer knows, that the interpretation is neither US oriented, but only oriented towards a specific locale. And then it might return a float or an integer and with correct error signaling.

[John O'Keefe]

On Wednesday, December 14, 2011 2:05:51 AM UTC-5, Marten Feldtmann wrote:

On the other hand it is even more questionable, that such a general method "asInteger" (without prefix) is introduced by a logging framework and not by a general library.

 

Marten -

I absolutely agree with you here -- it is not appropriate for features or add-ons to provide this sort of general method extension since it can lead to serious breakage. If we cannot agree on what the semantics of #asInteger should be, I will see that it is removed from the logging framework. Something needs to be done in any case because right now there are 2 different apps that provide the String>>#asInteger extension.

 

John

[John O'Keefe]

On Wednesday, December 14, 2011 1:16:10 AM UTC-5, jtu...@objektfabrik.de wrote:

I tend to be sceptical about a change. 

It is questionable if ' 33' is a number or an Integer, but if I as a developer want to make sure it is interpreted as one, I can always do a trimBlanks before I send #asInteger. There is a lot of space for interpretation in the whole area of String to number conversion and it is somewhat hard to draw a line. Should '.56' asInteger  be 0 or 1? Or should it throw an exception? Should '' asInteger answer 0 or throw an exception? And what about ' ' or 'x'?

 

Joachim -

 

Changing the semantics of general methods like #asInteger is normally a bad thing.  However, in this case, there are a limited number of options. Even though String>>#asInteger was introduced by the logging framework, this might not be noticable to developers (especially if it is provided as a suggestion by Code Assist). So, it seems that we either need to agree on its semantics and move it to the base or remove it completely.

 

The remainder of your points (all good) relate to the semantics of #asInteger and seem to be still debatable (at least to me).

 

John

 

 

[Gabriel Cotelli]

Hi

I never use this extension because I don't like the semantics: for example '99aaaXX' asNumber returns 99, and for me clearly this can't be parsed to a number, also '99A' asNumber could give the impression that it's a valid base 16 number and not 99. I think this kind of behavior just introduces subtle bugs.

IMHO the best approach is to have an IntegerParser to convert the String into an integer, and if the format is wrong just raise an exception. 

So, if somebody don't like the built-in parser, he can create his own parser.

+1 for the removal of the extension in the logging framework (in fact it already collides with DhbNumerics that also includes that extension).

Regards,

Gabriel

[Marten Feldtmann]

Then DhbNumerics should also be changed :-)))

[Thomas Koschate]

How do people feel about the behavior of EsString>>#abtAsInteger?  If the logging framework relies on the peculiarities of its own implementation of #asInteger, shouldn't the method be renamed to be particular to the logging framework?

Tom K

[John O'Keefe]

Thomas -

 

The one thing that isn't going to happen is for String>>#asInteger to remain in the logging framework. If it doesn' get moved to the base (with agreeable semantic -- which seems doubtful at this point based on the comments above), it will be removed in favor of the mis-named #asNumber method (which #asInteger redirects to anyway).  Then all the people who have added String>>#asInteger can fight it out among themselves :-)

 

John