[Pharo-project] about consistency between hex implementations
eliot.miranda at gmail.com
Mon Nov 8 22:39:27 CET 2010
On Mon, Nov 8, 2010 at 1:22 PM, Stéphane Ducasse
<stephane.ducasse at inria.fr>wrote:
> >> in pharo we have
> >> hex that always returns 16rXX
> >> $A hex '16r41'
> >> 20 hex '16r14'
> >> Even if this is regular this is not really nice. In fact this ones
> should be fixed to return numbers and not strings.
> >> I do not understand why hex should return a string.
> > And how? Integer >> #hex would be ^self and Character >> #hex would be
> ^value ?
> It looks like I proposed something stupid :) you are right we cannot
> generate 16r41 as a number. I was sure that we could do that so that I do
> not even check.
> This is strange that we cannot generate these numbers. This is strange to
> have things that we can only parse but not generate other than via strings.
> We could have something like Integer value: 65 base: 16 that returns 16r41
> and not 65 and not '16r41'
> When I type 16r41 my mental perception is not that this is a string but
> this is a number I'm manipulating.
> Like #foo, true,.... I do not think in terms of strings just objects. Now
> for true, #foo this is simpler because they only have one representation.
> Now the fact that several objects denotes the same elementary element is
> just an accident. So this was fun that I could think that :).
> Now my post had two topics and I would like at least to get the other
> fixed: consistency.
> $A hex '16r41'
> 20 hex '16r14'
> $A printStringHex
> 20 printStringHex
+1. The above definitions of hex are what VMMaker wants.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-project