Hi andreas

I will not state any related to our totally illness to do random  
refactorings
but can you tell me what is so deeply broken in the metaclass kernel?
I'm so idiot that I cannot even know it.

Stef


On 11 juil. 06, at 00:56, Andreas Raab wrote:

> Lukas Renggli wrote:
>> To improve software, it is required to break backward compatibility.
>> Nobody is forcing you to move to a new version.
>
> For starters, let's get our basic assumptions right: This  
> discussion isn't about people who do *not* want to move to new  
> versions. It's about people who *do* want and what expectations  
> they can have. Otherwise I'd agree with your statement.
>
>> If updates to the base-framework don't enhance anything in the
>> development process of your software, it is unnecessary to update. If
>> I were you, I would stick with 3.6. Still waters run deep.
>
> Well, if you were me, you would *want* to update. But you would  
> have noticed that things got so inconsistently broken at the  
> metaclass level that unless there are major pay-offs, it simply  
> isn't worth the effort. That's what happened from 3.6 to 3.7. In  
> 3.8 there was a major payoff - the m17n integration. That's why I  
> then spent the time needed. For 3.9, from a Tweak POV there isn't  
> that much interesting in there, so rather than going through the  
> painful porting exercise yet again I'll probably spend my time on  
> bootstrapping a stable (3.8-based) metaclass kernel which can be  
> used in parallel to the 3.9 kernel. Which is not particularly nice  
> but in the absence of any inclination towards stable APIs the only  
> alternative that I can see.
>
>> I have some legacy Seaside applications in ancient 3.6 images that  
>> run
>> just fine. They rarely change. They simply run fine. I won't port  
>> them
>> to 3.9 and a recent version of Seaside. These applications don't
>> require anything more as it is available in 3.6. However, for new
>> applications I take 3.9, I love
>> Shout/eCompletion/OmniBrowser/Traits/Pragmas/ToolBuilder/... I  
>> like to
>> keep up-to-date as long as it improves my productivity.
>
> You're totally missing my point. Let's take one example from your  
> list: ToolBuilder. Let's say you've got some work that uses it,  
> would you really expect that in each new Squeak version you have to  
> spend major effort to port your code to the latest ToolBuilder  
> version? Or wouldn't you rather expect that there is a stable API  
> that can be used and that may be extended over time, or even  
> broken, but if it's broken that you may get some notice about it  
> beforehand? Or, in particular when the changes get really  
> fundamental, that instead of modifying ToolBuilder in-place you get  
> the offer to use either ToolBuilder (working the way it always did)  
> and whatever the brand-new framework of the day is?
>
> I'm curious but is my position in this discussion really so  
> outrageous?
>
> Cheers,
>   - Andreas
>