[Pharo-project] about consistency between hex implementations
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
> 20 printStringHex
> +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 :)
More information about the Pharo-project