[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
http://bike-nomad.com
GPG key ID: BEEA7EFE




More information about the Squeak-dev mailing list