Given the age of new implementation, reversion consequences should be low.
I'd say please update Scanner>>xIllegal accordingly (otherwise 16r is
displayed twice)

There is also a bit of history in the tracker
http://bugs.squeak.org/view.php?id=6441
http://bugs.squeak.org/view.php?id=6339
http://bugs.squeak.org/view.php?id=6558
http://bugs.squeak.org/view.php?id=987

The 3 other implementors don't print any 16r, was it the motivation of new
hex implementation?
Anyway, hex is not that important, I doubt much squeakers will care.

What is more interesting is how to proceed with future changes, because some
have to break compatibility.
I think it would be good to have a tracker logging
- a list of uncompatible changes
- a good rationale justifying the change
- some guidelines for porting old packages (eventually automated RB rewrite
rules?)
If some change is rejected or reverted, it is good to have the rationale
logged too
(a link to mailing list thread is the least thing to do).

It is not really clear to me yet how the final decision is taken in case of
disagreement.
For example, I forced the selectors change (answering an Array rather than a
Set) despite negative advices from Bert and Eliot.
Andreas forced the 16r3e0 (lowercase hex) change despite having a minority
of support.
Jerome failed to impose his sound extension.

We don't need to define the decision process now, as long as trunk process
is going smoothly...

But a track of changes is important to any one wishing to update production
images, isn't it?

Nicolas

2010/7/18 Andreas Raab <andreas.raab at gmx.de>

> Thanks for the history. My vote is for restoring the original behavior of
> #hex and document it via tests.
>
> Cheers,
>  - Andreas
>
>
> On 7/17/2010 3:03 PM, Levente Uzonyi wrote:
>
>> 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
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100718/b30377cd/attachment.htm