My main objection is about growing the "mutator" nomenclature further
instead of trimming it back. 

I'm working on a GraphQL framework.
GraphQL has a first-class notion of "mutations".

  https://graphql.org/learn/queries/

Currently, we have almost zero mention of the word
"mutator" in the image.  I would appreciate if, instead of germinating
the overloading the word, we uproot it and keep the nomenclature for
this Smalltalk tooling confined to "getter" and "setter" that we have
now.

So, instead of #asMutator and #isMutator, how about #asSimpleSetter and
#isSimpleSetter?

We can end up removing a method instead of adding one.  We already
have many existing methods which are dealing with this conversion, all
of which use the traditional Smalltalk / developer linguisitic of
"setter".  Browsing through all the "setter" nomenclature we have in a
message names browser, including

  Utilities class>>#getterSelectorFor:
  Utilities class>>#setterSelectorFor:
  Utilities class>>#simpleSetterFor:

which instruct Etoys users to use existing methods on String,
#asSetterSelector or #asSimpleSetter.

Of special note is SyntaxMorph>>#isStandardSetterKeyword: which, by
its use of a utility-method implementation, acknowledges that this
behavior is _application-specific_.

I, myself, would just write:

      someSelector asSimpleSetter = someSelector  "same as isMutator /
isSimpleSetter"

instead of #isSimpleSetter, but can appreciate both styles.  They both
better avoid the awkwardness of "mutator" as a general, reliable
behavior when:

    #at: isMutator  "true"

while

    #at:put: isMutator   "false"

Best,
  Chris



On Thu, Mar 21, 2019 at 1:16 AM <patrick.rein@hpi.uni-potsdam.de> wrote:
>
> Which one are you refering to? I only see Symbol>>#asMutator in Collections in the method category converting. It is also used in a few other places beyond generating instance variable accessors.
>
> Bests,
> Patrick
>
> >#asMutator: is for "generate instVar accessors" code-generation, and
> >that's why it's in the Tools package.
> >
> >IMHO, if #isMutator belongs anywhere, it isn't in Collections.
> >
> >Regards,
> >  Chris
> >
> >
> >
> >On Wed, Mar 20, 2019 at 3:08 PM Chris Muller <asqueaker@gmail.com> wrote:
> >>
> >> Assuming a single-keyword is a mutator?  Object>>#at: is not a
> >> mutator.  #indexOf: is not.  #first: is not.  Obviously many more..
> >>
> >> If API balance is the goal of this, perhaps #asMutator should be
> >> removed instead.   This feels application-specific...
> >>
> >> On Wed, Mar 20, 2019 at 2:05 PM <commits@source.squeak.org> wrote:
> >> >
> >> > Patrick Rein uploaded a new version of Collections to project The Trunk:
> >> > http://source.squeak.org/trunk/Collections-pre.822.mcz
> >> >
> >> > ==================== Summary ====================
> >> >
> >> > Name: Collections-pre.822
> >> > Author: pre
> >> > Time: 20 March 2019, 8:05:20.383677 pm
> >> > UUID: 483c4461-cee4-4a4f-82d3-fbc03e7201cc
> >> > Ancestors: Collections-dtl.821
> >> >
> >> > Adds #isMutator to Symbol which is analogous to asMutator.
> >> >
> >> > =============== Diff against Collections-dtl.821 ===============
> >> >
> >> > Item was added:
> >> > + ----- Method: Symbol>>isMutator (in category 'testing') -----
> >> > + isMutator
> >> > +
> >> > +       ^ self isKeyword and: [self numArgs = 1]!
> >> >
> >> >
> >
>