Lex,

> This is exactly the kind of thing that makes me think refactoring
> or even rewriting a clean version of some core classes is entirely
> possible.  Morph was NOT always so simple, I'm pretty sure.  Was
> there always a single handleEvent?  That happened through
> refactoring.

Yes, by yours truly. But let me tell you that it's a pain in the neck to do
any such refactoring and that it introduces the need for other kinds of
complexities. In other words, the event handling stuff was moved out of
HandMorph since it became clear that there is a real need for responding to
events more flexibly than HandMorph could. But on the other hand, the same
functionality needed to be present (actually in a more complex fashion since
it needed to be more flexible) in Morphs themselves and this added probably
another 30-40 methods to it. So that - by the end of the day - the
refactoring itself introduced new complexity.

> I don't understand any of the massive philosophical debates going
> around.  Morphic has been developed with an exploratory 
> style, and it's entirely normal to shift into a cleanup phase
> now that things are better understood.  Let's just get on with it!

Lex, the massive philosophical debates are - at least as far as I am
concerned - centered around the question WHAT exactly it is that we now
understand better. Much of the discussions I've seen sounded more like
"let's just remove a few things here and there", "let's get rid of eToys",
which are all just "mechanical" refactorings which do not address any of the
deeper problems of it. Those who think that "eToys are the cruft" should
really think twice - *any* generally useful addition to "all objects" need
to have a place somewhere and it doesn't matter if you call it eToys or
Connectors or whatever. If you do not allow any additions you'll end up with
stagnation. If you do, you'll end up with complexity, one way or another. So
I think the key question to ask ourselves is how can we handle the
complexity in a better way. And that's why I'm pointing towards eToys.

> I will reply to one bit of philosophy that came up.  It doesn't
> matter if application writers follow the rules of the framework. 
> We just need to make sure the library itself follows them.  It
> doesn't matter whether TetrisMorph is entirely kosher -- it just
> needs to work.

True in one way. And wrong in about every other way. The key issue is that
people look and learn from examples so that even if the author is not aware
of it, someone may look at it and try to learn from it. This is simply how
learning works. And then, it is even more crucial that the framework is
capable of guarding itself, by introducing fences which require a certain
pain level to get across. Like, for example, the VM. It has a very high pain
level which is good for the most part - it makes sure that we don't get a
tetris morph which - just because it needs to work - changes a few byte
codes here and there.

Cheers,
  - Andreas