> #isMutator being simply wrong in many cases (e.g., #at:, #indexOf:,
etc.), this additional word feels application-specific.

More than a "feeling," but that is actually the reason.  You can't send
#isMutator to any Symbol and get a meaningful answer in any general sense.
Only in the context of some application-specific "code generator" or
whatever -- where the code knows it's dealing with getters and setters --
that anyone could rely on it.

IOW, application-specific.


On Sat, Jan 2, 2021 at 12:44 PM 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210105/9cdf8c6a/attachment.html>