Ok. I am agree '' asNUmber is wrong and should rise an error. I was just asking because in other smalltalks (where it is also wrong) it also returned zero. My concern is about portability between dialects. If people find porting stuff to Pharo difficult, they won't do it.
So, as suggested, I would implement, at least: Number>>asNumberOrZero ^self asNumberOr: 0 And Number>>asNumberOr: aNumber ^Number readFrom: self ifFail: [^aNumber] Can we all agree with this ? On Tue, Oct 20, 2009 at 11:55 AM, Nicolas Cellier < [email protected]> wrote: > 2009/10/20 <[email protected]>: > > Em 20/10/2009 10:04, Nicolas Cellier <[email protected]> > escreveu: > > > >> 2009/10/20 : > >>> I don't see where are we willing to arrive at. > >>> > >>> '' asNumber gives zero in several other Smalltalks (Dolphin and VW, > >>> for example) and used to work as Mariano mentions in earlier versions > >>> of Pharo (which makes me surmise is the way Squeak worked as well). > >>> > >>> So attempting addressing Nicolas point: the context where '' can be > >>> expected is when reading text from some other source (mainly text from > >>> a file) into you Pharo application. > >>> > >>> A library API has to have a reasonable balance between an excruciating > >>> "conceptual right" set of calls and the "principle of minimum > >>> surprise" for the corner cases in general. > >>> > >>> From this discussion, are we saying that for now on in order to have > >>> strings converted into numbers if we want to have the behaviour '' > >>> returning zero we shall change from '' asNumber to '' asNumberOrZero > >>> and this method will call a more general method like this? > >>> > >>> Number>>asNumberOrZero > >>> ^self asNumberOr: 0 > >>> > >>> And > >>> > >>> Number>>asNumberOr: aNumber > >>> ^Number readFrom: self ifFail: [^aNumber] > >>> > >>> Just my .0199999.... > >>> > >>> > >> > >> If this is an identified inter-dialect feature, then some applications > >> will rely on it, and then yes we SHOULD maintain the feature. > > > > Yes I think the crux is identifying if it is a feature that has become a > 'de facto standard' or not. . . > > > >> > >> But we can in no way keep all the silly other cases. > >> However, did you try these in other dialects > > > > FWIW: > > > >> ' ' asNumber. > > > > Returns 0 in VW and an exception in Dolphin (note that if you put '' > instead of ' ' in Dolphin it returns zero instead) > > > >> 'a' asNumber. > > > > Returns 0 in VW and an exception in Dolphin. > > > >> 'b2' asNumber. > > > > Returns 0 in VW and an exception in Dolphin. > > > >> etc... > > > > ST/X generates exceptions for all the cases above. > > > > > >> > >> I guess VW & Dolphin should fail in all these cases... > >> Squeak did not and would answer 0 in most cases, and that's what I > >> don't want to see anymore... > >> > >> Another question is should we authorize non blank trailing characters > >> ? I think no. > >> '2r' asNumber. > >> '2 + 3' asNumber. > >> etc.. > >> > > > > We had a discussion about this in another thread but we did not arrived > at a final position if memory serves me. > > > > [snipped] > > > > HTH > > > > In squeak, that started almost 4 years ago, and I remember some > complaints too in vwnc list around that time. > > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/103137.html > http://bugs.squeak.org/view.php?id=3512 > > Nicolas > > > -- > > Cesar Rabak > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
