[squeak-dev] Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)
Tim Johnson
digit at sonic.net
Sat Jan 2 18:44:39 UTC 2021
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
|