readFrom: aStringOrStream base: base
"Answer an instance of one of the concrete subclasses if Integer.
Initial minus sign accepted, and bases > 10 use letters A-Z.
Imbedded radix specifiers not allowed; �use Number
class readFrom: for that.
Raise an Error if there are no digits.
If stringOrStream dos not start with a valid number description, answer 0 for backward compatibility. This is not clever and should better be changed."

^(SqNumberParser on: aStringOrStream) failBlock: [^0]; nextIntegerBase: base

Mmm, I hate backwards compatibility ��. �Maybe we can...

1) create a new Integer>>fromStringOrAnotherNameThatPleaseUs: which fails when it has to :)
2) deprecate the old one?� So we can change the dependants gradually.


On Tue, Aug 24, 2010 at 10:16 AM, Johan Brichau <johan@inceptive.be> wrote:
>
> On 24 Aug 2010, at 15:01, Guillermo Polito wrote:
>
>>>> I opened a ticket http://code.google.com/p/pharo/issues/detail?id=2854
>>>
>>> +1
>>> Are you already onto it? If not, I can make my hands dirty on this one ;-)
>>
>> All yours I think :P.
>
> great :-/
>
> Anyway, the problem goes down to Integer>>readFromString: which returns 0 if the string does not represent a number. The comment says something about backwards compatibility, so we'll have to approach the issue with care but having 0 as the error value is flabbergasting to me.
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>