Re-doing Morphic ( Was: Re: Traits prototype image )

Daniel Vainsencher danielv at netvision.net.il
Tue Feb 11 17:39:13 UTC 2003


Andreas Raab <andreas.raab at gmx.de> wrote:
> 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.

In this case, as you state, there was a functional need, so the
complexity had a purpose, within the framework. It's reasonable to add
some complexity inside the framework to make things simpler for it's
clients. This sort of thing is one part of preventing clients requiring
patches to the framework itself.

> 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'm not sure I understood you direction here - I'm assuming you mean
that the complexity eToys brings into Morphic is not a root cause, but a
symptom (as you say later - of lacking fences). I agree it's a symptom,
but - bad oxygen supply to the brain is sometimes just a symptom, but it
still kills people.

As you say, if most people misunderstand Morphic, we'll forever have
more bad Morphic examples than good ones, causing a vicious cycle. Etoys
is an example that screams out "to build an application in Morphic, you
need to patch Morph with references to your applications".

So moving aside alot of the currently builtup "cruft" is a necessary,
though, as you say, insufficient, condition to getting Morphic well.

> > 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. 
Yup, it's a key point.

> And then, it is even more crucial that the framework is
> capable of guarding itself, 
True...

> 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.
Now that kind of pain is just one possible mechanism. As we get more and
more pacakges in SM, I think we're learning some things about what it'll
take to scale. One conclusion I make is - *for a package to patch it's
prerequisites is a bad thing*. Packages that do this should be marked
red, as in "here lies Pain".

When people assume their Morphic example will be a package, not part of
the image, and know they don't want their package to not be red, we'll
have a good fence in place.

Other kinds of fences might be added as SUnit tests. For example, 

MorphFrameworkTestCase>>structure
	self assert: Morph subclasses < N.

If loading your package breaks your prerequisites tests, you've been
bad, and you'll get told as much.

Daniel



More information about the Squeak-dev mailing list