[squeak-dev] would anyone object if I committed my changes to Integer>>hex?

Levente Uzonyi leves at elte.hu
Sat Jul 17 22:03:25 UTC 2010


On Sat, 17 Jul 2010, Eliot Miranda wrote:

> Hi All,
>
>    in creating the Cog VMMaker image from Squeak 4.1 that is in the svn
> tree for Cog (http://www.squeakvm.org/svn/squeak/branches/Cog) I had to
> revert a change made to Integer>>hex.  I don't want to point fingers but it
> was IMO an unnecessary change; one can always add a new selector if one
> wants new behaviour and existing code (in this case VMMaker) depended on the
> old behaviour.  BTW, the difference is that originally Integer>>hex (&
> Integer>>hex8) prefixed their hex output with the base so that 123 hex is
> '16r7B' and 123 hex8 '16r0000007B', whereas the new semantics omits the
> prefix so that 123 hex is '7B'.  The old semantics is depended on by various
> tests as well it providing the convenience of being able to select and print
> the result.  I would like to revert the behavior, essentially because a) one
> should not unnecessarily break backwards-compatibility and b) Cog is
> potentially useful to a lot of the community.  So views for or against?  Or
> should I make it, gack, a VMMaker override (gack, please nooooo)?

The story of #hex is a bit more complicated. It was deprecated in 3.8, 
removed in 3.9 and was reintroduced in 3.10 with different semantics. 
The last decision was definitely bad. But what about the removal? Why 
was it removed in 3.9? The idea was to use #printStringHex and 
#storeStringHex instead of #hex. The problem with the removal was that 
it wasn't done properly. There were senders of the removed #hex method in 
the 3.9 image and the external packages weren't updated.

If we want to follow the decision of removing #hex from the image, then 
#hex should be an extension method in VMMaker or #storeStringHex should 
be used (yeah, it's a long name).
If we want to keep #hex in the image, then I think we should restore the 
original semantics.


Levente

>
> best
> Eliot
>



More information about the Squeak-dev mailing list