<div dir="ltr"><div dir="ltr">Hi Tim,</div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">First, before the rest of this complain-y message:<br>
<br>
**Happy 2021 to everybody!**<br></blockquote><div><br></div><div>To you as well!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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></blockquote><div><br></div><div>Yes, the conflict is in the design of the language of the system and its API.  Smalltalkers have forever used the terms, "getters and setters," not "getters and mutators".  GraphQL, OTOH, provides a first-class, formal definition of a "mutation".</div><div><br></div><div>(BTW, I never did announce the GraphQL engine, but it's on squeaksource, a solid and complete package).</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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></blockquote><div><br></div><div>As mentioned in the original discussion, besides #isMutator being simply wrong in many cases (e.g., #at:, #indexOf:, etc.), this additional word feels application-specific.  The systems above are all specific, external applications.  I would recommend introducing the "mutator" lingo into Grease for Squeak and keep it out of the core library.  We should stick with as minimal a set of words as possible.  "Getters and setters," is the lingo.  Otherwise, where does it end?  Every word has several synonyms.  It starts to get messy quickly.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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><br></blockquote><div><br></div><div>These links and high-profile name look impressive until you follow them and look at their usage of "mutator" in context.  As you pointed out, the first two of the four links refer to the same, single, idle usage in a single sentence.  Not a "definition" of any sort.  And the third is just the name of a one temporary variable.  Pretty weak as an argument for inclusion.</div><div><br></div><div>That leaves just the last one, a more obscure Smalltalk, unrelated to Squeak?  I'm not familiar with that project, but they might be interested in switching to the "getters and setters" linguistic.</div><div></div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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></blockquote><div><br></div><div>Yes.  Both.  The code must target a specific version of Squeak (to be reliable), so it can be easily done without package conflicts.  Even real, unavoidable conflicts are not something to necessarily abhor -- it's usually due to flexing of Smalltalk muscles, being able to run with a modified system is one of its beautiful and powerful features.</div><div><br></div><div> - Chris</div></div></div>