[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