would anyone object if I committed my changes to Integer>>hex?
Locked
would anyone object if I committed my changes to Integer>>hex?
 
|
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)?
best Eliot
|
Re: would anyone object if I committed my changes to Integer>>hex?
|
|
VMMaker override? Yeesh. So it's a prim then? I say, revert it; Cogit ergo go-fast is worth breaking a few packages when I'm trying to convince my boss to let me solve problems in Smalltalk.
Can we just add a (not primitive) method #terseHex that uses the old #hex mechanism, and strips off the base and leading zeroes? That would at least give folks depending on it a quick fix for any breakage that might occur.
On Sat, Jul 17, 2010 at 2:21 PM, Eliot Miranda <[hidden email]> wrote: Hi All, -- Casey Ransberger |
Re: would anyone object if I committed my changes to Integer>>hex?
|
|
In reply to this post by Eliot Miranda-2
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 > |
Re: would anyone object if I committed my changes to Integer>>hex?
|
|
Okay I promise I won't touch this thread again, but I say we make Cog happy and cheer up whatever that depresses.
On Sat, Jul 17, 2010 at 3:03 PM, Levente Uzonyi <[hidden email]> wrote:
-- Casey Ransberger |
Re: would anyone object if I committed my changes to Integer>>hex?
|
|
In reply to this post by Levente Uzonyi-2
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 >> 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 >> > > |
Re: would anyone object if I committed my changes to Integer>>hex?
|
|
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 <[hidden email]> Thanks for the history. My vote is for restoring the original behavior of #hex and document it via tests. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |