[Cuis-dev] Morph method prefixes

[Juan Vuletich]

Hi Mark,

On 8/24/2024 3:22 PM, Mark Volkmann via Cuis-dev wrote:
> Is there a story behind why the following method names in the Morph 
> class begin with "morph"?

Good question! (See below)

>
> morphExtent
> morphExtentInOwner
> morphId
> morphLocalBoundsForError
> morphPosition
> morphPosition:
> morphPositionInWorld
> morphPositionInWorld:
>
> It seems like the "morph" prefix could be removed without any loss in 
> clarity.
> There are many other methods in the Morph class whose names do not 
> have that prefix.
>
> It seems uncommon for method names to begin with their class name. For 
> example, a Dog class might have methods like name and breed, but 
> wouldn't typically have methods like dogName and dogBreed.
>
> -- 
> R. Mark Volkmann
> Object Computing, Inc.

There are, perhaps, 3 different groups of selectors. For very few, like 
#morphId, #morphBoundsAfterDraw and maybe others are used in other 
classes, and as they are about the morph they are dealing with, it just 
seemed right to me.

Others, like #morphPositionInWorld and such, were created when I 
converted the Morphic framework from Squeak's style global coordinates 
to Morph local coordinates. It was a way to separate the two semantics 
while they were both there, during that redesign. So, they are no longer 
needed. I just pushed a few updates to rename them, and to deprecate the 
old implementations. They will be removed later.

Finally, we have others like #morphPosition, #morphExtent and such. The 
problem with them is that #position and #position: are part of the 
Stream protocol. #extent and #extent: are part of Form and Rectangle 
protocol. This looks like polymorphism, but it isn't. In no way a Morph 
and a Stream can be used in the same code. Same for a Morph and a Form, 
or a Morph and a Rectangle. In this cases, when using Senders and 
Implementors in such messages, you need to keep in your mind the fact 
that they form two distinct subsets of senders and implementors that 
will never intersect. The lists of senders and implementors become twice 
as large for no reason, and working in that code is much harder than needed.

Yes, I really dislike false polymorphism. So #morphPosition, 
#morphExtent and a few others have the 'morph' prefix only so they are 
never confused with Stream, Form and Rectangle protocol.

I hope this helps.

And thank you for bringing attention to this. I think the resulting 
cleanup of some of those names improves code readability.

Cheers,

-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240825/be945d75/attachment.htm>