[Cuis-dev] Renaming several fundamental Morph classes
Hilaire Fernandes
hilaire at drgeo.eu
Tue Dec 28 02:01:44 PST 2021
Indeed, proper a name will be easier to pick up if we merge the two
classes Kernel+Widget/Morph.
I like the idea about the properties. I don't see the impact though when
used in core classes. May be less discoverable. But with proper
documentation in the classes, it should not be much a concern.
But I guess for a core class as a BorderedMorph, with instances
occurring in many part of the system, it is better to have attributes,
for efficiency concerns as you mentioned it.
If we merge these two classes, we can lower even more the complexity of
the Morph hierarchy. That's a cool side benefit.
There are very little subclasses of KernelMorph (borderless) :
*HaloHandle*, *Halo*, *Hand*, *PasteUp*. The vast majority are subclass
of WidgetMorph (with border). It shows that KernelMorph (aka BoxedMorph,
etc) is not useful. Moreover, all these 4 classes but Hand may want to
use a border as you can read from their respective drawOn: methods.
Concerning the Hand, it could be turned as a direct subclass of
MoveableMorph.
These discussions are nice opportunity to think about the whole Morph
hiererachy.
Hilaire
Le 28/12/2021 à 08:47, Luciano Notarfrancesco a écrit :
> How about just BorderedMorph?
>
> Also, I should mention that using “properties” turned out very useful
> in my project to separate inheritance from some implementation
> details. I have a “properties” instance variable in the superclass,
> and I use properties instead of instance variables in most cases. This
> allows to use inheritance more cleanly, without inheriting instance
> variables, and particular subclasses can override replace some
> properties by instance variables if desired (for example for speed).
> This also allows to make “abstract classes” that are actually concrete
> and can be instantiated.
--
GNU Dr. Geo
http://drgeo.eu
http://blog.drgeo.eu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20211228/e454fa59/attachment.htm>
More information about the Cuis-dev
mailing list