[Pharo-project] about consistency between hex implementations

Eliot Miranda 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
>        '41'
> 20 printStringHex
>        '14'
>

+1.  The above definitions of hex are what VMMaker wants.


> Stef
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20101108/808ffd37/attachment.htm>


More information about the Pharo-project mailing list