Hi Ned ,

On Thu, 21 Jun 2001, Ned Konz wrote:

> 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 
> menus.
> 
> > 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 bike-nomad.com
> homepage:  http://bike-nomad.com
>


Thank you Ned, for your reply. It is helpful to see how somebody
who did a considerable add-in to Morphic perceives this.

Your response motivated me to come up with the calculation belowe.

"Squeak 3.1-3910"

"Build Collection of all the Morph method selectors"
(s _ Morph selectors asSortedCollection) inspect


"How many methods has class Morph?"
s size  970


"Build collection of method selectors which are defined within class
Morph but
the methods are sent from outside:

Go through s and look  generate a list of senders for each selector. Then 
check this
list if there is a least one sender from the outside of class Morph and
keep this selector.
The following calulation needs a long time."

calledFromOutSide _
((s select: [ :sel |
((Smalltalk allCallsOn: sel) detect:
[ :eachMethod | (eachMethod asString  findTokens: ' ') first asSymbol ~=
#Morph]  ifNone: [ nil]) notNil]) asSortedCollection) inspect

"How many?"
calledFromOutSide size  710

Is this calculation correct?

Actually 710 methods of class Morph seem to be called from other classes
(including subclasses of Morph). 
This actually means that 970 - 710 = 260 methods are private to class
Morph.

But 710 methods is still an enormously heigh number. Every book on OO
design I have in my
library strongly discourages this. 

I think the next interesting thing could be to count how many methods are 
defined in class
Morph but actually only called from a subclass.  This would give the
number of methods
which could be moved into subclasses. This seems to me to be much more
difficult to calculate.
The next thing would be to come up with a script which automatically
moves these methods
to an appropriate subclass.
What do you think about this?

Regards

Hannes