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

Marcel Taeumel marcel.taeumel at hpi.de
Tue Jan 5 10:42:54 UTC 2021


Hi Tim! :-)

> 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?


(a), I suppose, which is common for maintaining compatibility with several Smalltalk dialects and versions. Note that clients can turn 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

Best,
Marcel
Am 02.01.2021 19:44:49 schrieb Tim Johnson <digit at sonic.net>:
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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210105/472ca946/attachment.html>


More information about the Squeak-dev mailing list