About squeak image compatibility (3.6/7/8)
stéphane ducasse
ducasse at iam.unibe.ch
Mon Jan 9 10:55:19 UTC 2006
>
> * you actually start using 3.9, in which case you'll have issues
> with porting back stuff to older Squeak versions (this will be a
> serious issue for packages that are and should be used in older
> versions of Squeak - will these older versions of Monticello be
> able to deal with class definition that have been created in 3.9? etc)
Normally this should be no problem.
Traits should not have impact at this level, if you do not use it
they should not get in your way.
> * 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. I know that you fix the classBuilder and it was good (there
are some fixes still to harvest in 3.9).
For the SmalltalkImage and Smalltalk cleaning. The key aspect here is
that it would have been much better that we do not have to slice our
work and try to be backward compatible solution.
Now the situation is the following
- it is like ProjectRefactoring: in the middle of nowhere.
- and you shouted so much on us (I do not blame you for that, I can
imagine that you were losing time
and I understand that this can be a real pain still I want to
describe the results)
saying that we were doing random refactorings for example, that I'm
not even sure that noone will ever try to finish.
I still would like to totally implement the idea I propose in 3.9
proposal (but I decided that this will not be
for 3.9).
- while the situation could have been much better (I do not think
that cleaning the kernel
should be done more than once every 10 years so once it is done, it
would be fixed)
if we would have done it in one shot.
Now we had to produce cs and pray so that our changes would get
considered, then
the system changes. For some of the fixes I had to redo them 5 times.
> * you use meta tools that rely on the previously available semantic
> entities (which excludes traits)
I do not understand what you mean there.
> * you use meta tools that rely on previously stable representations
> (class definitions in particular)
>
> 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.
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).
>
> And of course, another major difference in perspective is whether
> you are on the breaking or the broken side of things. People don't
> like their stuff to get broken by other people so any claim that
> this is "extremely little" is not likely to get you many friends -
> in particular if the breakage (as so often) is undocumented and
> you'll probably find out the hard way. And I think you'd be well
> advised to keep that in mind.
More information about the Squeak-dev
mailing list
|