<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Hi Tim! :-)<div><br></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> So: what is the long term strategy here? After methods are deprecated</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> and removed from the image, when those methods served the purpose of</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> compatibility with 3rd party packages and other Smalltalks, is it expected</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> that each outside package will either (a) maintain its own compatibility</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> layer, like Grease, or (b) implement the removed methods via class</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> extensions, thus possibly introducing conflicts?</span><br></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-size: 13px;font-family: Arial, Helvetica, sans-serif">(a), I suppose, which is common for maintaining compatibility with several Smalltalk dialects and versions. Note that clients can t</span><span style="font-size: 13px;font-family: Arial, Helvetica, sans-serif">urn off deprecation warnings before loading any not-updated package. When, at some point, a certain deprecation package is not in the release (or trunk) anymore, clients can re-load those packages as they remain available through source.squeak.org/trunk</span></div><div><span style="font-size: 13px;font-family: Arial, Helvetica, sans-serif"><br></span></div><div><span style="font-size: 13px;font-family: Arial, Helvetica, sans-serif">Best,</span></div><div><span style="font-size: 13px;font-family: Arial, Helvetica, sans-serif">Marcel</span></div><div class="mb_sig"></div>
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 02.01.2021 19:44:49 schrieb Tim Johnson <digit@sonic.net>:</p><div style="font-family:Arial,Helvetica,sans-serif">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>http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html<br>http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html<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:  https://github.com/hpi-swa/Squot/issues/266<br>Seaside: https://github.com/SeasideSt/Seaside/issues/1195<br>Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator<br>HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860<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>https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d<br><br>^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" <br>(2007) <br>https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html<br><br>See also: "simple accessor and mutator methods" (1998)<br>http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html<br><br>and: ST/X's asMutator (in protocol 'converting')<br>https://live.exept.de/ClassDoc/classDocOf,CharacterArray<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></div></blockquote></div>