>>> * 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.

***I will look at that because I REALLY want to know. I hate breaking  
stuff without knowing it***
>
>>> * 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.

Yes I see. Indeed adding a new entity is a challenge.

>>> 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..."


Ok I understand your point.

>> 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 interesting...

Google steal him from us. :)
But I sincerly think that the v1 is simple and that even with all the  
care, this simplicity is really still introducing a new feature.
When I see the evolution of Java and C# I think that Smalltalk is  
great since we do not have new crazy features.
I learned to really help the method annotation (coming also soon in  
3.9) much better than the namespace introduction in VW.

>
> [*] 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.

Indeed

> 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.

I'm guessing what you mean ( we need a black board). My main problem  
today is how this is possible that we do not invent
a way to deal with all these versions alltogether leaving happily in  
the same "image". I trying to understand why we have the evolution  
problems. The language seems not to take into account evolution and  
changes. But I do not have concrete and reasonable solution.

Stef