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

Chris Muller asqueaker at gmail.com
Tue Jan 5 21:59:29 UTC 2021

Hi Tim,

First, before the rest of this complain-y message:
> **Happy 2021 to everybody!**

To you as well!

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

Yes, the conflict is in the design of the language of the system and its
API.  Smalltalkers have forever used the terms, "getters and setters," not
"getters and mutators".  GraphQL, OTOH, provides a first-class, formal
definition of a "mutation".

(BTW, I never did announce the GraphQL engine, but it's on squeaksource, a
solid and complete package).

> 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

As mentioned in the original discussion, besides #isMutator being simply
wrong in many cases (e.g., #at:, #indexOf:, etc.), this additional word
feels application-specific.  The systems above are all specific, external
applications.  I would recommend introducing the "mutator" lingo into
Grease for Squeak and keep it out of the core library.  We should stick
with as minimal a set of words as possible.  "Getters and setters," is the
lingo.  Otherwise, where does it end?  Every word has several synonyms.  It
starts to get messy quickly.

> 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
These links and high-profile name look impressive until you follow them and
look at their usage of "mutator" in context.  As you pointed out, the first
two of the four links refer to the same, single, idle usage in a single
sentence.  Not a "definition" of any sort.  And the third is just the name
of a one temporary variable.  Pretty weak as an argument for inclusion.

That leaves just the last one, a more obscure Smalltalk, unrelated to
Squeak?  I'm not familiar with that project, but they might be interested
in switching to the "getters and setters" linguistic.

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

Yes.  Both.  The code must target a specific version of Squeak (to be
reliable), so it can be easily done without package conflicts.  Even real,
unavoidable conflicts are not something to necessarily abhor -- it's
usually due to flexing of Smalltalk muscles, being able to run with a
modified system is one of its beautiful and powerful features.

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

More information about the Squeak-dev mailing list