[squeak-dev] Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

Tobias Pape Das.Linux at gmx.de
Tue Jan 5 11:09:26 UTC 2021


Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.-
Narf.

-t

> On 2. Jan 2021, at 19:44, Tim Johnson <digit at sonic.net> wrote:
> 
> 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
> 
> 
> 




More information about the Squeak-dev mailing list