Tweak mainstream in Squeak

Andreas Raab andreas.raab at gmx.de
Tue Jul 11 07:27:17 UTC 2006


Hi Stef -

I'm actually way beyond where I want to discuss these issues. I've been 
trying to leave that stuff behind but when a message like Lex' comes in 
where it basically says that it's my fault that Tweak doesn't work in 
3.9 (as if it were by my choice) it just annoys me to no end.

The question I was raising, however, was and is serious: What, if any, 
is the plan for the metaclass kernel? Are there, for example, any plans 
for major traits refactoring? If so, it'd be nice if a little bit of a 
strategy could be layed out so that, for example, I can plan accordingly.

Cheers,
   - Andreas

stéphane ducasse wrote:
> 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
>>
> 
> 
> 




More information about the Squeak-dev mailing list