[etoys-dev] together again

[Jecel Assumpcao Jr]

Göran Krampe wrote:

> I agree that it may be premature, but since the discussion was brought 
> up I wanted to make it clear that some of us out here don't consider 
> ourselves "eToys haters" *nor* do we want an intertangled base.

Indeed. I think it is good to have these discussions now. I will start
by confessing that I have not looked at the Etoys code to see what the
problem is, so am only repeating what other people have said. I can
imagine some issues, though:

1) things hidden in obscure places

This would complicate removing more than reloading. It could lead to an
image that is supposed to be Etoys free actually having methods or even
whole classes left in. These would be missing from any generated Etoys
package, but since they would still be in the main image any code in the
package that depends on them would still work. And we can suppose that
this would be relatively small compared to what was removed and so
wouldn't bother people too much.

2) changing, rather than deleting, methods

It is often that case that some methods would still be needed without
Etoys but only one or a few of its lines would have to be eliminated or
rewritten. Reloading Etoys wouldn't work unless these methods were
restored to their previous versions as part of the package loading. But
any later changes to these methods would be lost this way and other
things would break. Doing this right requires some careful programming.

3) circular dependencies

This is often cited as the most significant problem. Rather than having
Etoys as a clean layer on top of Morphic you have parts of Morphic that
do their job by using Etoys stuff. This is why Bert suggested making
Etoys+Morphic one big reloadable package instead of trying to separate
the two. I think enough people want Morphic without Etoys (Cuis, Pharo
and others) that I feel we should at least try to evaluate what kind of
an effort it would be to separate them. Obviously people have already
been able to rip out Etoys in a way that satisfied them and that already
involved dealing with circular dependencies. Perhaps these efforts leave
pieces of Etoys in place?

There is another discussion which I would like to have: what will Etoys
be like in the future? The current Squeakland Foundation roadmap
indicates that it will be basically what we have now in a few years,
which isn't what I would like. We have several programming environment
in Squeak: Smalltalk-80, Etoys from Squeakland, Etoys from Squeak.org,
Scratch, tiles (broken), alternative syntax (removed in recent Squeaks,
right?) and a few others that are external packages. I would like to see
a nicer path from Scratch-->Etoys-->Smalltalk-80 and if we go in that
direction then Etoys would be even more integrated into the system
rather than less.

-- Jecel