Hi,

First, before the rest of this complain-y message:

**Happy 2021 to everybody!**

Now to shamefully bring up a closed matter:  in 2019 there was some 
discussion on the mailing list that led to the deprecation of #asMutator. 
Some portions of the discussion can be seen here:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html
http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html

Part of the argument was that "asMutator" and the notion of "mutators" was 
not seen elsewhere in the image, and that it conflicted with work someone 
was doing with GraphQL (?) which has its own notion of "mutators".  Was 
there other rationale?

In the meantime, various teams and projects will have to adapt their code. 
And, users have been coping with various packages not loading seamlessly 
in Squeak 5.3 due to this deprecation.

Squot:  https://github.com/hpi-swa/Squot/issues/266
Seaside: https://github.com/SeasideSt/Seaside/issues/1195
Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator
HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860

I'm sorry for bringing up a settled matter, and for grandstanding a bit 
("at what price progress?"), but:  was #asMutator deprecated because of 
the argument that "mutators" are alien to Smalltalk and/or Squeak?  If so, 
I (respectfully) have a hard time accepting part of that argument.  A 
quick Google search turns up much literature.

"To add an accessor method and a mutator method" (2015)
https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d

^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" 
(2007) 
https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html

See also: "simple accessor and mutator methods" (1998)
http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html

and: ST/X's asMutator (in protocol 'converting')
https://live.exept.de/ClassDoc/classDocOf,CharacterArray

So:  what is the long term strategy here?  After methods are deprecated 
and removed from the image, when those methods served the purpose of 
compatibility with 3rd party packages and other Smalltalks, is it expected 
that each outside package will either (a) maintain its own compatibility 
layer, like Grease, or (b) implement the removed methods via class 
extensions, thus possibly introducing conflicts?

Thanks,
Tim