Tweak mainstream in Squeak

Wolfgang Eder edw at generalmagic.at
Mon Jul 10 23:06:34 UTC 2006


Colin Putney wrote:
> 
> On Jul 10, 2006, at 4:22 PM, Julian Fitzell wrote:
> 
>> I'm not saying don't break compatibility, I'm just saying be aware 
>> every time that you are doing it.  And the thought that there be a 
>> relatively stable API for a core set of classes that doesn't change 
>> without some forethought is perfectly reasonable, in my opinion.  At 
>> least then, when compatibility is broken, detailed instructions could 
>> be provided on how to update your software in each case.
> 
> Here, here. I'll add an example of the kind of incompatibility that I, 
> at least, am frustrated by.
> 
> I try to keep OmniBrowser compatible with Squeak 3.6 and later. Prior to 
> 3.9, you can fetch a menu icon for delete operations by sending 
> #deleteIcon to the class MenuIcons. In 3.9 you have to send 
> #smallDeleteIcon. As far as I can tell, the change is completely 
> gratuitous. The icon is small, yes, but there's no corresponding 
> #largeDeleteIcon.  #deleteIcon was just removed, it wasn't changed to 
> call through to #smallDeleteIcon or even deprecated.
> 
> Apparently, I have to jump through some hoops to make menus work in 
> Squeak 3.9 because somebody wanted to make the selectors more 
> consistent. I'm all for progress, but this kind of thing is just 
> irritating.
> 
> Colin

Hi,
this example demonstrates the main reason why I think
the "full" image is so important:
If, at the point of this refactoring (or renaming, whatever),
the author had your OmniBrowser loaded, it would have been
no big deal to just make the required changes.
Using the RB, you get most of these changes *for free*.

It's so much less work this way, compared to trying to find
out what has changed, exactly, between newer versions.
Cheers
Wolfgang



More information about the Squeak-dev mailing list