[Q] Subclassing. was: Making a button immune...

Ned Konz ned at bike-nomad.com
Sun Apr 14 14:00:11 UTC 2002

On Saturday 13 April 2002 02:47 pm, Martin Drautzburg wrote:

> That brings up another question: I frequently hesitate to create a
> new class, especially if it is only for "internal" reasons. Maybe I
> should just go ahead.

Much of Morphic is pluggable at the object level; the EventHandlers 
are set up for this, as are the properties. Unfortunately, 
SimpleButtonMorph's response to mouseDown is not (though if you mark 
it as a parts donor it won't respond to mouseDown events).

Perhaps you should try marking it as a parts donor:

myButton isPartsDonor: true

though I still don't understand what a SimpleButtonMorph that doesn't 
handle mouse events does that is any different than, say, a TextMorph 
inside a BorderedMorph.

> OTOH there is some good reason behind my hesitation: for another
> person it will not be obvious which classes are ment for public use
> and which are for internal use.
> Now you may argue that every class is for public use, but still:
> seeing a screw and a car engine on the same parts list may make the
> list hard to read, especially when there are many more screws than
> car engines on the list and you really are interested in the car
> engines only.
> Is there a solution for that ?

Class categories or modules would seem to present a solution, though 
there's not much use of them for hiding internal classes yet. You can 
look at (for instance) the category "Morphic-Text Support" which 
appears to have all internal classes.

I'd be in favor of having sub-categories that hide "internal" classes 
(i.e. not usefully part of the external interface).

Also, as far as Morphs go, ones that are made for end-user use 
generally appear in the Objects tool (i.e. their class responds to 
descriptionForPartsBin or supplementaryParts Description), and they 
tend to return true to includeInNewMorphMenu.

Ned Konz

More information about the Squeak-dev mailing list