<div dir="ltr">> #isMutator being simply wrong in many cases (e.g., #at:, #indexOf:, etc.), this additional word feels application-specific.<div><br></div><div>More than a "feeling," but that is actually the reason.  You can't send #isMutator to any Symbol and get a meaningful answer in any general sense.  Only in the context of some application-specific "code generator" or whatever -- where the code knows it's dealing with getters and setters -- that anyone could rely on it.</div><div><br></div><div>IOW, application-specific.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 2, 2021 at 12:44 PM Tim Johnson <<a href="mailto:digit@sonic.net" target="_blank">digit@sonic.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
First, before the rest of this complain-y message:<br>
<br>
**Happy 2021 to everybody!**<br>
<br>
Now to shamefully bring up a closed matter:  in 2019 there was some <br>
discussion on the mailing list that led to the deprecation of #asMutator. <br>
Some portions of the discussion can be seen here:<br>
<br>
<a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html" rel="noreferrer" target="_blank">http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html</a><br>
<a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html" rel="noreferrer" target="_blank">http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html</a><br>
<br>
Part of the argument was that "asMutator" and the notion of "mutators" was <br>
not seen elsewhere in the image, and that it conflicted with work someone <br>
was doing with GraphQL (?) which has its own notion of "mutators".  Was <br>
there other rationale?<br>
<br>
In the meantime, various teams and projects will have to adapt their code. <br>
And, users have been coping with various packages not loading seamlessly <br>
in Squeak 5.3 due to this deprecation.<br>
<br>
Squot:  <a href="https://github.com/hpi-swa/Squot/issues/266" rel="noreferrer" target="_blank">https://github.com/hpi-swa/Squot/issues/266</a><br>
Seaside: <a href="https://github.com/SeasideSt/Seaside/issues/1195" rel="noreferrer" target="_blank">https://github.com/SeasideSt/Seaside/issues/1195</a><br>
Also Seaside: <a href="https://github.com/SeasideSt/Seaside/search?q=asMutator" rel="noreferrer" target="_blank">https://github.com/SeasideSt/Seaside/search?q=asMutator</a><br>
HPI "Home Desktop System": <a href="http://wiki.squeak.org/squeak/2860" rel="noreferrer" target="_blank">http://wiki.squeak.org/squeak/2860</a><br>
<br>
I'm sorry for bringing up a settled matter, and for grandstanding a bit <br>
("at what price progress?"), but:  was #asMutator deprecated because of <br>
the argument that "mutators" are alien to Smalltalk and/or Squeak?  If so, <br>
I (respectfully) have a hard time accepting part of that argument.  A <br>
quick Google search turns up much literature.<br>
<br>
"To add an accessor method and a mutator method" (2015)<br>
<a href="https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d" rel="noreferrer" target="_blank">https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d</a><br>
<br>
^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" <br>
(2007) <br>
<a href="https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html" rel="noreferrer" target="_blank">https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html</a><br>
<br>
See also: "simple accessor and mutator methods" (1998)<br>
<a href="http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html" rel="noreferrer" target="_blank">http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html</a><br>
<br>
and: ST/X's asMutator (in protocol 'converting')<br>
<a href="https://live.exept.de/ClassDoc/classDocOf,CharacterArray" rel="noreferrer" target="_blank">https://live.exept.de/ClassDoc/classDocOf,CharacterArray</a><br>
<br>
So:  what is the long term strategy here?  After methods are deprecated <br>
and removed from the image, when those methods served the purpose of <br>
compatibility with 3rd party packages and other Smalltalks, is it expected <br>
that each outside package will either (a) maintain its own compatibility <br>
layer, like Grease, or (b) implement the removed methods via class <br>
extensions, thus possibly introducing conflicts?<br>
<br>
Thanks,<br>
Tim<br>
<br>
<br>
<br>
</blockquote></div>