Ned Konz ned at
Thu Jun 21 23:48:21 UTC 2001

On Thursday 21 June 2001 14:24, Hannes Hirzel wrote:

> you say it wasn't easy for you to understand the class Morph (obvious if
> it has 1000 methods - imagine a C program with 1000 functions).

There's a difference in those examples. A C program with 1000 functions is 
probably using all of them. The methods in Morph are often not used by 
anything in the image; they're there to make it easy for programmers. This is 
a difference between an application and a framework.

[later] well, I was going to say that, but it appears that only 63 of the 
selectors in Morph aren't called in my image.

	(Smalltalk allUnSentMessagesIn: (Morph selectors)) size

Still, many of these are probably only called from within Morph.

Also, there's nothing that says you have to know about all these 1000 methods 
to make a Morph work.

Some of these categories don't even need to be looked at, generally -- eToy 
support, genie, geometry eToy, pen, scripting, player*, etc. include hundreds 
of methods, and I have never used one of them as far as I know.

There are also a lot of methods for Morph structure traversal; you see a lot 
of the Collection sorts of methods being duplicated in Morph. (see the 
structure and submorphs* categories).

Also, many of the Morph methods exist mostly so they can be called from the 

> Could you give some examples of the things you found most difficult to
> understand?

The rather involved event handling chain was tricky. After Andreas changed 
it, it was somewhat nicer, but can still be hard to follow, especially if 
you're trying to do something out of the ordinary.

Making non-standard event handlers (see Morph>>processEventUsing and 
MorphicEventDispatcher) can be hard to get right or to follow.

veryDeep copying took some learning to get right, especially since I have 
Morphs that have references to other Morphs that aren't submorphs.

There is a lot of interaction with the Hand (you should probably add the 
HandMorph methods and the PasteUpMorph methods if you're trying to get a feel 
for Morphic complexity).

Transformations, especially nested ones, can be hard to debug. And you have 
to make sure that you do them right if you're writing event handlers that 
use world coordinates.

This also applies to nested PasteUpMorphs with separate transforms.

The combined operation of the ParagraphEditor, CharacterScanner, and 
PluggableTextMorph are, um, a bit intricate.

> Do you have any suggestions for refactoring?

It all depends on what a Morph is supposed to be able to do. Note that one of 
the reasons that Morph got bigger was that specific functionality got moved 
into it:

* any morph can be a button (not just *Button*Morph classes)
* any morph now knows how to do fancy layout (not just AlignmentMorph)
* any morph can be dropped into a piano roll
* morphs know how to print themselves
* morphs have an extendable set of halos

etc. There's a lot of functionality that *any* morph possesses that would be 
hard or inefficient to reorganize. Some of this has already been done (like 
with layout policy objects).

One of the things I'd like to see is a refactoring of the menu code; rather 
than hard-wired menus, I'd like to see a menu repository that could be edited.

But I'm not sure that making a Morph class has to be all that terrifying. 
Like any other framework, you need to get over the idea that you should (or 
can) understand it all before you use it.

Ned Konz
currently: Stanwood, WA
email:     ned at

More information about the Squeak-dev mailing list