[Pharo-project] about consistency between hex implementations
dmason at mason-rose.ca
Mon Nov 8 22:59:36 CET 2010
On Nov 8, 2010, at 16:22, Stéphane Ducasse wrote:
> 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.
16r41 is a *representation* of a number, just as 10r65, 65, 2r1000001 are... and all representations of the same number. The convention is that when numbers are displayed to use, they are in decimal, but presumably that is just an artifact from the number of fingers we have.
> Now the fact that several objects denotes the same elementary element is just an accident. So this was fun that I could think that :).
No, they're all the same object: 10r65
> 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
I think those are exactly the right definitions. Use: '16r', 20 printStringHex
if that's what you want.... otherwise, if you want to string multiple hex strings together you have to remove the 16r from each of them first. e.g.
'16r', 20 printStringHex, $A printStringHex
More information about the Pharo-project