<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Mark,<br>
<br>
On 8/24/2024 3:22 PM, Mark Volkmann via Cuis-dev wrote:
<blockquote
cite="mid:CAFfRWnVVC4CZDzG+ff26CgDETv9vbDkd2eDFMA2yy-D0b=DZcg@mail.gmail.com"
type="cite">
<div dir="ltr">Is there a story behind why the following method
names in the Morph class begin with "morph"?</div>
</blockquote>
<br>
Good question! (See below)<br>
<br>
<blockquote
cite="mid:CAFfRWnVVC4CZDzG+ff26CgDETv9vbDkd2eDFMA2yy-D0b=DZcg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
<div>morphExtent</div>
<div>morphExtentInOwner</div>
<div>morphId</div>
<div>morphLocalBoundsForError</div>
<div>morphPosition</div>
<div>morphPosition:</div>
<div>morphPositionInWorld</div>
<div>morphPositionInWorld:</div>
<div><br>
</div>
<div>It seems like the "morph" prefix could be removed without
any loss in clarity.</div>
<div>There are many other methods in the Morph class whose
names do not have that prefix.</div>
<div><br>
</div>
<div>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.</div>
<div>
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div><font face="arial, helvetica, sans-serif">R.
Mark Volkmann</font></div>
<div><span style="font-size: 12.8px;"><font
face="arial, helvetica, sans-serif">Object
Computing, Inc.</font></span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I hope this helps.<br>
<br>
And thank you for bringing attention to this. I think the resulting
cleanup of some of those names improves code readability.<br>
<br>
Cheers,<br>
<pre class="moz-signature" cols="72">--
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</pre>
</body>
</html>