ned at bike-nomad.com
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
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
* 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.
currently: Stanwood, WA
email: ned at bike-nomad.com
More information about the Squeak-dev