[Q] Subclassing. was: Making a button immune...
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.
GPG key ID: BEEA7EFE
More information about the Squeak-dev