Hi

On Thu, Mar 28, 2019 at 8:15 AM <patrick.rein at hpi.uni-potsdam.de> wrote:

> Sorry to open this up again. I have progressed well in shuffling things
> around. However: While moving the corresponding test cases I noticed that
> there is also #isBinary, #isDoIt, #isInfix, #isUnary, #isKeyword, and
> #isPvtSelector implemented on Symbol. Given that these all exist, I would
> rather keep #asSimpleSetter, #isSimpleSetter, #asSetterSelector in the
> Collections package.
>
> Any other oppinions on that?
>

isPvtSelector, isUnary, isInfix, isKeyword, isDoIt - all similar to your
new isMutator (and all mostly used in MethodFinder, Shout, and
occassionally compiler).  I'd prefer to see them moved off to
tools/system/compiler similarly, although that feeling isn't as strong as
some of the other commentators previously.  But it is re-enforced by the
#isBinary selector.

#isBinary is a stinker.  First off, it just delegates to #isInfix on
Symbol.  But it is also on many other classes in Collections, where it
deals with wheither or not the stream is a binary stream or not - in other
words, completely unrelated to the meaning of #isBinary on Symbol (and
shoutParser).  I would think pulling this one out for sure from Collections
would be good - even better would be to stop using it for this purpose and
instead directly use #isInfix.  (Although I suspect it is called from
packages outside of base Squeak - maybe VMMaker?)

If you don't want to move these, I'd be happy too (as long as overall
consensus doesn't swing away from this direction).

Thanks,
cbc

>
> Bests
> Patrick
>
> >Sounds good to me!
> >
> >How about the following: I would deprecate #asMutator/#isMutator in favor
> of #asSimpleSetter and #isSimpleSetter. At the same time I would move the
> #asSimpleSetter up from Symbol to String where #asSetterSelector already
> resides. Finally, I would move both pairs of selectors to the Tools (or
> System or Compiler?) package (I would rather not keep them scattered across
> MorphicExtras and Etoys as common selectors would then also be used by
> System).
> >
> >Bests,
> >Patrick
> >
> >>
> >>
> >>On Thu, Mar 21, 2019 at 1:03 PM Chris Muller <asqueaker at gmail.com>
> wrote:
> >>
> >>My main objection is about growing the "mutator" nomenclature further
> >>instead of trimming it back.
> >>
> >>
> >>+1
> >>
> >>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.
> >>
> >>
> >>+1
> >>
> >>So, instead of #asMutator and #isMutator, how about #asSimpleSetter and
> >>#isSimpleSetter?
> >>
> >>
> >>+1
> >>
> >>
> >>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"
> >>
> >>
> >>+1000. Chris is right. isMutator is a mistake.
> >>
> >>
> >>Best,
> >>Chris
> >>
> >>
> >>
> >>On Thu, Mar 21, 2019 at 1:16 AM <patrick.rein at 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 at 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 at 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]!
> >>> >> >
> >>> >> >
> >>> >
> >>>
> >>
> >>
> >>
> >>--
> >>_,,,^..^,,,_
> >>best, Eliot --000000000000004a690584a05ffa--
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190328/4af701be/attachment.html>