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
interesting...
[*] 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.
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|