About squeak image compatibility (3.6/7/8)

Andreas Raab andreas.raab at gmx.de
Tue Jan 10 00:44:10 UTC 2006

stéphane ducasse wrote:
>> * you assume a stable interface in classes and meta classes (this  got 
>> seriously broken in 3.7, then again in 3.8, and now again in  3.9 - it 
>> is amazing how little continuity there has been in such a  critical 
>> part of the system)
> I suspect that you refer to the changes we did to try to clean the  
> kernel. I do not see where the classes and metaclasses interfaces  
> changes.

Well, if you are really curious, you could have a look at the references 
to CSqueak3Point8Detected in a Tweak image. This will point out the 
areas in which there were plain inconsistencies in the class and 
metaclass interfaces (there are others which can be dealt with by extra 
overrides but those changed in semantically inconsistent ways). In 3.9 I 
actually don't know yet what concretely is broken since I only gave a 
quick try - which resulted in a series of errors that in all likeliness 
are due to class/metaclass changes (there is a small chance that the 
problem is elsewhere, I'll admit that but I really don't think that's 
very likely). And given the pain that I went through porting to 3.8 I 
really didn't feel like investigating this more closely right now. It 
was just one of those "oh, well, realistically speaking, what did you 
expect..." kind of things.

>> * you use meta tools that rely on the previously available semantic  
>> entities (which excludes traits)
> I do not understand what you mean there.

Tools like Rosetta which bild a semantic model from source code. Adding 
new semantic entities means all of those tools represent the (new) 
structures inadequately.

>> Now, I'm not saying that everyone will be affected by (or even care  
>> about) the above but if you are in either situation it is pretty  safe 
>> to assume you'll be severely screwed one way or another. Case  in 
>> point: Without appropriate fixes Monticello and file contents  browser 
>> are invariably broken (and so is the VW parcel that allows  people to 
>> load Squeak code).
> Why don't report that to us?
> I always like the way you shot at people instead of notifying them.

I didn't say you didn't fix these issues. Indeed you did. But it doesn't 
change the fact that those fixes were *required* that without those 
fixes these tools were utterly broken. Mind you, this discussion started 
with Cees asking for what compatibility issues were introduced by adding 
traits and I'm merely pointing these out. That issues have been fixed 
doesn't mean they didn't exist, which is how I read Cees' claim about 
"extremely little" compatibility issues, e.g., that typically nothing 
would break after adding traits - and for those areas that I'm pointing 
to, that's just not true. And that's why I said "very little, unless..."

> Should I conclude that when you said to nathanael that you wanted him  
> to work on traits for Tweak or whatever this
> was not quite true? Or do you meant a package loadable traits (I'm  
> trying to be fair here).

I don't know what you are trying to say here. Again, this discussion 
started by Cees asking for what compatibility issues have been created 
by traits. I have listed them, *and* I have pointed out that quite a 
number of people might not care about them. What this has to do with 
Nathanael or traits in Tweak I don't know.

But since you are raising the issue what I *have* been talking about 
with Nathanael is to get an END-USER version of traits into Tweak - one 
that requires an algebraic foundation but that by no means should be 
used by the end user in the way that he's been proposing (e.g., by 
annotating class definitions). Personally, I think that Nathanel nailed 
the model - what he (in my view) didn't nail very well was the usability 
issues. Also, if you will remember that this is "Traits v1" - and I was 
*always* arguing for something that (given that versioning scheme) could 
best be called traits v3 (e.g., it goes beyound what Nathanael thought 
about for the "extended" version, incl. encapsulation etc). So, yeah, I 
think this is an interesting model[*] (and definitely worth giving 
someone a PhD for since this is ground work that future generations can 
build upon) but it's still a ways away from where we *ought* to be if 
there would be such a thing as software "engineering". And so, in a way 
my main complaint is that he stopped working on it when it just got 

[*] To be even more plain about this I feel like Nathanael has solved 
the harder, yet less interesting problem, namely how to flatten 
behaviors and organize composition around that flattened behavior. The 
reason why I'm saying it's the "less interesting" problem is that it 
ignores objects - in a way this is an algebra which allows us to munge a 
set of functions into a namespace. The usefulness of his work lies in 
being able to express what this "munging" means and to consequently 
describe its use, the potential conflicts and proposed solutions (incl. 
aspects of reusability etc). For an end-user scripting system I think 
it's okay to do that (the end-user will in many places think about 
functions anyway and it would enable a number of pretty cool 
interactions) but in a way, it's ultimately non-oop to do that - these 
*should* be objects and interactions between objects and you really 
should't just dump a whole lot of functions into a namespace (in a way, 
that's no different from "include foo.c"). Anyway, end of rant for now.

   - Andreas

More information about the Squeak-dev mailing list