Smalltalk › Instantiations

Number>>#fromString:

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

Richard Sargent (again)

Number>>#fromString:

If one evaluates "Integer fromString: '8000'", one would expect to receive an Integer result. Unfortunately, the implementation of #fromString: in Number is deceptive. Yes, it answers a Number. But it doesn't answer a number representative of the string.

[There is a similar issue with String>>#asNumber. It always and only answers an Integer, instead of a the type of number represented by the String. In fact, it pretends a string of rubbish is a valid integer.]

Can we get these methods improved? In fact, it would be desirable for these methods to correspond to the language parser.

[I will leave unspecified whether there should be methods that ban the radix prefix in the string to be converted. e.g., Integer fromBase10String: '8000' would produce the expected result while Integer fromBase10String: '16r2000' would produce an error, as would the string '8000.0'. If supported, the base should be something one could control.]

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.

Marten Feldtmann-2

Re: Number>>#fromString:

Am Sonntag, 9. Februar 2014 22:28:09 UTC+1 schrieb Richard Sargent:

Can we get these methods improved? In fact, it would be desirable for these methods to correspond to the language parser.

Why ? This general idea might be nice for US programmers, but we have seen in the past in this product, that its not good to think only in US-oriented ways - but look at European or Asian needs ...

Wayne Johnston

Re: Number>>#fromString:

In reply to this post by Richard Sargent (again)

Integer fromString: '8000'

answers a SmallInteger 8000, same as if I type 8000 and inspect it. That seems good to me. What are you expecting?

I see this implementation in Integer class is from the WbWidgets application - is that what you are seeing?

fromString: aString

^aString asNumber

Yes it's a little funny that String>>#asNumber only/always answers an integer. I would have voted for the method to be called #asInteger instead. But it's too late to change the behavior of #asNumber without breaking code that likes that behavior. Sometimes I use #abtAsNumber but that has weird behavior such as

'8.1 q' abtAsNumber

answers 8.001

And if you don't like somebody, have them execute

'42E123456' abtAsNumber

Richard Sargent

Re: Number>>#fromString:

Administrator

On Monday, February 10, 2014 4:17:31 AM UTC-8, Wayne Johnston wrote:

Integer fromString: '8000'
answers a SmallInteger 8000, same as if I type 8000 and inspect it. That seems good to me. What are you expecting?

I see this implementation in Integer class is from the WbWidgets application - is that what you are seeing?

fromString: aString
^aString asNumber

What I see in a clean 8.5.2 image (New Image), is the following, sole implementation of #fromString: in the Number hierarchy.

fromString: aString
^aString wbAsFloat

Richard Sargent

Re: Number>>#fromString:

Administrator

In reply to this post by Marten Feldtmann-2

On Sunday, February 9, 2014 10:07:46 PM UTC-8, Marten Feldtmann wrote:

Am Sonntag, 9. Februar 2014 22:28:09 UTC+1 schrieb Richard Sargent:
Can we get these methods improved? In fact, it would be desirable for these methods to correspond to the language parser.

Why ? This general idea might be nice for US programmers, but we have seen in the past in this product, that its not good to think only in US-oriented ways - but look at European or Asian needs ...

Marten, I am clearly not following the direction of your argument. I agree with you that the US localization is not the only one in the world. However, I was not requesting the ability to parse localized number representations. That is a worthwhile addition in its own right. I would expect to invoke that via some expression similar to " Locale current readIntegerFromString: '8 000' ", for example.

What I am requesting is that the hierarchy of Number produce results of the class requested. e.g., Integer class>>#fromString: should answer an Integer while Float class>>#fromString: should answer a Float.

Additionally, I am requesting these existing conversion methods recognize Smalltalk syntax, since that is (sort of) locale neutral and well-defined.

Marten Feldtmann-2

Re: Number>>#fromString:

Ok, after reading these statements I would say: all these conversion (convenient) methods are the source of many, many problems and it would be *much* better NOT to use them and to do these conversions with special converter classes (considering locales) - then the reader knows what it is expected to happen here.

Therefore throw away all these methods (though it will really hurt :-)))) - and nothing would run any more)

Carl Gundel-2

Re: Number>>#fromString:

So, obsolete them in VA Smalltalk 8.7, and then get rid of them (or at least sanitize them) in VA Smalltalk version 9. Go through the pain and be better for it on the other side.

-Carl

On Monday, February 10, 2014 3:30:12 PM UTC-5, Marten Feldtmann wrote:

Ok, after reading these statements I would say: all these conversion (convenient) methods are the source of many, many problems and it would be *much* better NOT to use them and to do these conversions with special converter classes (considering locales) - then the reader knows what it is expected to happen here.

Therefore throw away all these methods (though it will really hurt :-)))) - and nothing would run any more)

Richard Sargent

Re: Number>>#fromString:

Administrator

On Tuesday, February 11, 2014 6:37:06 AM UTC-8, Carl Gundel wrote:

So, obsolete them in VA Smalltalk 8.7, and then get rid of them (or at least sanitize them) in VA Smalltalk version 9. Go through the pain and be better for it on the other side.

Fine. I don't want to tell Instantiations how to implement the functionality. That's not our job.

I would like to see the functionality improved, so that one has control over the class of number being created and the ability to parse all numeric literal strings complying with Smalltalk syntax. It would be nice to see the additional functionality of being able to parse localized numbers in strings, but that is an adjunct.

If there were to be a "Smalltalk" locale that one could refer to, that would provide a certain parsimony of implementation, so admittedly a reasonable approach. (But again, it is Instantiation's right and responsibility to choose *how* they provide functionality.)

Carl Gundel-2

Re: Number>>#fromString:

On Tuesday, February 11, 2014 12:17:57 PM UTC-5, Richard Sargent wrote:

On Tuesday, February 11, 2014 6:37:06 AM UTC-8, Carl Gundel wrote:
So, obsolete them in VA Smalltalk 8.7, and then get rid of them (or at least sanitize them) in VA Smalltalk version 9. Go through the pain and be better for it on the other side.

Fine. I don't want to tell Instantiations how to implement the functionality. That's not our job.

I would like to see the functionality improved, so that one has control over the class of number being created and the ability to parse all numeric literal strings complying with Smalltalk syntax. It would be nice to see the additional functionality of being able to parse localized numbers in strings, but that is an adjunct.

If there were to be a "Smalltalk" locale that one could refer to, that would provide a certain parsimony of implementation, so admittedly a reasonable approach. (But again, it is Instantiation's right and responsibility to choose *how* they provide functionality.)

If you just keep on adding new stuff without getting rid of the old, you end up living in a big, ugly hodge podge of a house full of clutter.

-Carl

John O'Keefe-3

Re: Number>>#fromString:

Carl -

While I can't help but agree about 'a house full of clutter', clearing out the clutter is not so easy. For example, you can see that we still ship an ENVY/Image Obsolete PI map that contains classes and methods obsoleted in VisualAge Smalltalk 4.0, but still used.

In addition to deprecating stuff in one release and removing it in some later release, we would also have to provide some code-rewrite rules for the RB (similar to what is done for Seaside in Seaside-Slime). But even then, making such a change causes our customers extra effort for no value (at least none that they can see), so it has to be done quite carefully (even removing private methods causes issues because 'private' is just annotation -- it isn't enforced). We continue to look for a solution, but nothing good has shown up.

John

On Tuesday, February 11, 2014 5:55:20 PM UTC-5, Carl Gundel wrote:

On Tuesday, February 11, 2014 12:17:57 PM UTC-5, Richard Sargent wrote:
On Tuesday, February 11, 2014 6:37:06 AM UTC-8, Carl Gundel wrote:
So, obsolete them in VA Smalltalk 8.7, and then get rid of them (or at least sanitize them) in VA Smalltalk version 9. Go through the pain and be better for it on the other side.

Fine. I don't want to tell Instantiations how to implement the functionality. That's not our job.

I would like to see the functionality improved, so that one has control over the class of number being created and the ability to parse all numeric literal strings complying with Smalltalk syntax. It would be nice to see the additional functionality of being able to parse localized numbers in strings, but that is an adjunct.

If there were to be a "Smalltalk" locale that one could refer to, that would provide a certain parsimony of implementation, so admittedly a reasonable approach. (But again, it is Instantiation's right and responsibility to choose *how* they provide functionality.)

If you just keep on adding new stuff without getting rid of the old, you end up living in a big, ugly hodge podge of a house full of clutter.

-Carl

Carl Gundel-2

Re: Number>>#fromString:

John,

Sure, I know it isn't easy to clear out the clutter. It's not always practical to do what I was suggesting, but whenever you can, you should. It can be very hard work, but the rewards can make it worthwhile.

But, I do think it's usually wrong to solve these sorts of problems by continually adding more buttons and levers. That's really the position I am trying to state.

Less is more.

So, inspired by that idea I'll stop here. ;-)

Thanks,

-Carl

On Wednesday, February 12, 2014 12:53:30 PM UTC-5, John O'Keefe wrote:

Carl -

While I can't help but agree about 'a house full of clutter', clearing out the clutter is not so easy. For example, you can see that we still ship an ENVY/Image Obsolete PI map that contains classes and methods obsoleted in VisualAge Smalltalk 4.0, but still used.

In addition to deprecating stuff in one release and removing it in some later release, we would also have to provide some code-rewrite rules for the RB (similar to what is done for Seaside in Seaside-Slime). But even then, making such a change causes our customers extra effort for no value (at least none that they can see), so it has to be done quite carefully (even removing private methods causes issues because 'private' is just annotation -- it isn't enforced). We continue to look for a solution, but nothing good has shown up.

John

On Tuesday, February 11, 2014 5:55:20 PM UTC-5, Carl Gundel wrote:

On Tuesday, February 11, 2014 12:17:57 PM UTC-5, Richard Sargent wrote:
On Tuesday, February 11, 2014 6:37:06 AM UTC-8, Carl Gundel wrote:
So, obsolete them in VA Smalltalk 8.7, and then get rid of them (or at least sanitize them) in VA Smalltalk version 9. Go through the pain and be better for it on the other side.

Fine. I don't want to tell Instantiations how to implement the functionality. That's not our job.

I would like to see the functionality improved, so that one has control over the class of number being created and the ability to parse all numeric literal strings complying with Smalltalk syntax. It would be nice to see the additional functionality of being able to parse localized numbers in strings, but that is an adjunct.

If there were to be a "Smalltalk" locale that one could refer to, that would provide a certain parsimony of implementation, so admittedly a reasonable approach. (But again, it is Instantiation's right and responsibility to choose *how* they provide functionality.)

If you just keep on adding new stuff without getting rid of the old, you end up living in a big, ugly hodge podge of a house full of clutter.

-Carl