[Pharo-project] about consistency between hex implementations

Stéphane Ducasse stephane.ducasse at inria.fr
Mon Nov 8 23:09:48 CET 2010


On Nov 8, 2010, at 10:39 PM, Eliot Miranda wrote:

> 
> 
> 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.

Ok I will send you a cs for squeak!
Now I'm fighting with MC on something else (instead of writing a nice letter for a Phd evaluation :)


>  
> Stef
> 





More information about the Pharo-project mailing list