About squeak image compatibility (3.6/7/8)

Samir Saidani saidani at squeakfr.org
Sun Jan 8 21:28:27 UTC 2006


Cees De Groot <cdegroot at gmail.com> writes:

> We are simply afraid that if we introduce a new, better interface, we
> may break old code and this old code will be hard to repair. All other
> reasons, I feel, are just dragged into the arena of debate by their
> hairs in order to prevent us having to confess this very simple fact.
>
> We have the finest development tools in the world, and we're afraid to
> use them.

I'm not sure that it is right, even if you state it. Personally, I'm
interested in understanding what is elegance and efficiency, and in
particular here when writing code. There is no fear in that, just a
passion I would say. I don't stick to squeak, there is other
interesting initiatives.

> I say: compatibility is not a major goal. It's nice to have, but
> shouldn't become a burden. Because if we introduce major breakage (say
> by kicking out everything files and network, loading flow, and
> declaring that the next version of Squeak), you have two options:

> So. that's out :-). I have painted my arguments in black-and-white on
> purpose, because I really want this discussion going. I want to have
> some sort of simple policies around maintenance of Squeak, where I
> would propose "unmaintained packages are not included" and "backwards
> compatibility is not a major goal but compatibility changes should be
> well documented and well announced".

You are opposing "backward compatibility" and "compatibility changes"
: I think that there is no contradiction between this two term, it is
a matter of attention and care. If you read the first mail I sent,
"compatibility changes" is treated on the point 4 : "4. If global
compatibility can not be insured, it should be mentionned explicitly
to developers into the image itself.", compatibility is a matter of
intelligently designing the code which leads to elegance and economic
reuse (and it is the same movement behind the "object"
design). Compatibility is not a goal, but a matter to take care of the
code, and if things should be broken, there is no problem if attention
is here.

Cheers,
Samir.





More information about the Squeak-dev mailing list