The Trunk: Collections-pre.822.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

The Trunk: Collections-pre.822.mcz

commits-2
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]!


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-pre.822.mcz

Chris Muller-3
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 <[hidden email]> 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]!
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-pre.822.mcz

Chris Muller-3
#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 <[hidden email]> 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 <[hidden email]> 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]!
> >
> >

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-pre.822.mcz

patrick.rein
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 <[hidden email]> 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 <[hidden email]> 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]!
>> >
>> >
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-pre.822.mcz

Chris Muller-3
In reply to this post by Chris Muller-3
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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]!
> >> >
> >> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-pre.822.mcz

Eliot Miranda-2


On Thu, Mar 21, 2019 at 1:03 PM Chris Muller <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-pre.822.mcz

patrick.rein
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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--

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-pre.822.mcz

Hannes Hirzel
In reply to this post by Eliot Miranda-2
On 3/22/19, [hidden email]
<[hidden email]> wrote:
> 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).

+1

> Bests,
> Patrick
>
>>
>>
>>On Thu, Mar 21, 2019 at 1:03 PM Chris Muller <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> > 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 <[hidden email]> 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--
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-pre.822.mcz

Chris Muller-4
> On 3/22/19, [hidden email]
> <[hidden email]> wrote:
> > 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).
>
> +1

Sounds good, thanks!

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-pre.822.mcz

patrick.rein
In reply to this post by Eliot Miranda-2
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?

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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--
>

cbc
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-pre.822.mcz

cbc
In reply to this post by Eliot Miranda-2
Hi

On Thu, Mar 28, 2019 at 8:15 AM <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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--
>



Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-pre.822.mcz

Chris Muller-3
In reply to this post by Eliot Miranda-2
> 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?

Virtually every classic description of the Smalltalk language in books
and classes I can remember talks about

   "three kinds of message names, unary, binary, and keyword..."

For example, here it is on the Complete Smalltalk Syntax on a Postcard:

     https://medium.com/@richardeng/syntax-on-a-post-card-cb6d85fabf88

So, I think those three belong in Collections.

"Setter" relates to making a setter method.  That's tooling.  So the
only reason I would have anything "setter" in Collections is if there
are enough senders from different depending packages that Collections
is the only common ancestor between them.

Best,
  Chris

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-pre.822.mcz

patrick.rein
I am almost done with moving selectors around and migrating code. One last proposal while I am at it. In line with Cris Cunninghams observation that #isBinary is quite ambiguous on Strings/Symbols, would moving to #isUnarySelector, #isBinarySelector, and #isKeywordSelector be an option? It would improve consistency and be more descriptive. At the same time it might break compatibility with other dialects.

Bests,
Patrick

P.S.: Thanks for staying with me on this topic. I just feel that making the protocols more consistent / accessible while being at it can make the whole system more accessible in the long run. :)

>> 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?
>
>Virtually every classic description of the Smalltalk language in books
>and classes I can remember talks about
>
>   "three kinds of message names, unary, binary, and keyword..."
>
>For example, here it is on the Complete Smalltalk Syntax on a Postcard:
>
>     https://medium.com/@richardeng/syntax-on-a-post-card-cb6d85fabf88
>
>So, I think those three belong in Collections.
>
>"Setter" relates to making a setter method.  That's tooling.  So the
>only reason I would have anything "setter" in Collections is if there
>are enough senders from different depending packages that Collections
>is the only common ancestor between them.
>
>Best,
>  Chris
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-pre.822.mcz

patrick.rein
In reply to this post by Eliot Miranda-2
I finally came around to finish this. Please find attached a changeset which:
- deprecates #asMutator and removes #isMutator
- refactors existing calls to #asSimpleSetter
- moves #as*Setter to the category System-Support

Depending on further comments I would merge these in the next days/weeks.

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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--
>
["mutatorAndSetter.1.cs"]


mutatorAndSetter.1.cs (19K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-pre.822.mcz

Tobias Pape

> On 20.08.2019, at 17:51, <[hidden email]> <[hidden email]> wrote:
>
> I finally came around to finish this. Please find attached a changeset which:
> - deprecates #asMutator and removes #isMutator
> - refactors existing calls to #asSimpleSetter
> - moves #as*Setter to the category System-Support
>
> Depending on further comments I would merge these in the next days/weeks.

¯\_(ツ)_/¯

I actually liked the name mutator


>
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> _,,,^..^,,,_
>>> best, Eliot --000000000000004a690584a05ffa--
>>
> ["mutatorAndSetter.1.cs"]



Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-pre.822.mcz

Levente Uzonyi
In reply to this post by Eliot Miranda-2
On Tue, 20 Aug 2019, [hidden email] wrote:

> I finally came around to finish this. Please find attached a changeset which:
> - deprecates #asMutator and removes #isMutator

What will be the replacement for #asMutator?

Levente

> - refactors existing calls to #asSimpleSetter
> - moves #as*Setter to the category System-Support
>
> Depending on further comments I would merge these in the next days/weeks.
>
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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--
>>
> ["mutatorAndSetter.1.cs"]

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-pre.822.mcz

marcel.taeumel
#isSimpleSetter :-)

Best,
Marcel

Am 20.08.2019 21:33:47 schrieb Levente Uzonyi <[hidden email]>:

On Tue, 20 Aug 2019, [hidden email] wrote:

> I finally came around to finish this. Please find attached a changeset which:
> - deprecates #asMutator and removes #isMutator

What will be the replacement for #asMutator?

Levente

> - refactors existing calls to #asSimpleSetter
> - moves #as*Setter to the category System-Support
>
> Depending on further comments I would merge these in the next days/weeks.
>
> 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 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 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 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 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--
>>
> ["mutatorAndSetter.1.cs"]



Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-pre.822.mcz

Levente Uzonyi
Hi Marcel,

I suppose you meant #asSimpleSetter, but that is not an exact substitute.

Case #1:
#foo: asSimpleSetter "==> #'foo::'"
#foo: asMutator "==> #foo:"

Case #2:
#'' asSimpleSetter "==> #':'"
#'' asMutator "==> Error: subscript is out of bounds: 0"

So, if the plan is to go with the name #asSimpleSetter, I suggest the
implementation should keep the behavior of #asMutator in Case #1.
Also, #copyWith: is faster than #,. :)


Levente

On Wed, 21 Aug 2019, Marcel Taeumel wrote:

> #isSimpleSetter :-)
> Best,
> Marcel
>
>       Am 20.08.2019 21:33:47 schrieb Levente Uzonyi <[hidden email]>:
>
>       On Tue, 20 Aug 2019, [hidden email] wrote:
>
>       > I finally came around to finish this. Please find attached a changeset which:
>       > - deprecates #asMutator and removes #isMutator
>
>       What will be the replacement for #asMutator?
>
>       Levente
>
>       > - refactors existing calls to #asSimpleSetter
>       > - moves #as*Setter to the category System-Support
>       >
>       > Depending on further comments I would merge these in the next days/weeks.
>       >
>       > 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 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 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 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 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--
>       >>
>       > ["mutatorAndSetter.1.cs"]
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-pre.822.mcz

patrick.rein
Hi Levente,

this is what the new implementation in the changeset does, it replace the implementation of asSimpleSetter with the implementation from asMutator :) Do you think the behavior of #asSimpleSetter in Case #2 is worth having?

Bests
Patrick

>Hi Marcel,
>
>I suppose you meant #asSimpleSetter, but that is not an exact substitute.
>
>Case #1:
>#foo: asSimpleSetter "==> #'foo::'"
>#foo: asMutator "==> #foo:"
>
>Case #2:
>#'' asSimpleSetter "==> #':'"
>#'' asMutator "==> Error: subscript is out of bounds: 0"
>
>So, if the plan is to go with the name #asSimpleSetter, I suggest the
>implementation should keep the behavior of #asMutator in Case #1.
>Also, #copyWith: is faster than #,. :)
>
>
>Levente
>
>On Wed, 21 Aug 2019, Marcel Taeumel wrote:
>
>> #isSimpleSetter :-)
>> Best,
>> Marcel
>>
>>       Am 20.08.2019 21:33:47 schrieb Levente Uzonyi <[hidden email]>:
>>
>>       On Tue, 20 Aug 2019, [hidden email] wrote:
>>
>>       > I finally came around to finish this. Please find attached a changeset which:
>>       > - deprecates #asMutator and removes #isMutator
>>
>>       What will be the replacement for #asMutator?
>>
>>       Levente
>>
>>       > - refactors existing calls to #asSimpleSetter
>>       > - moves #as*Setter to the category System-Support
>>       >
>>       > Depending on further comments I would merge these in the next days/weeks.
>>       >
>>       > 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 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 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 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 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--
>>       >>
>>       > ["mutatorAndSetter.1.cs"]
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-pre.822.mcz

Tobias Pape
In reply to this post by Levente Uzonyi

> On 21.08.2019, at 11:57, Levente Uzonyi <[hidden email]> wrote:
>
> Hi Marcel,
>
> I suppose you meant #asSimpleSetter, but that is not an exact substitute.
>
> Case #1:
> #foo: asSimpleSetter "==> #'foo::'"
> #foo: asMutator "==> #foo:"
>
> Case #2:
> #'' asSimpleSetter "==> #':'"
> #'' asMutator "==> Error: subscript is out of bounds: 0"
>
> So, if the plan is to go with the name #asSimpleSetter, I suggest the implementation should keep the behavior of #asMutator in Case #1.

+1

> Also, #copyWith: is faster than #,. :)

yeah, but #, is the canonical concatenation for Smalltalk.
I see no reason to optimize.

>
>
> Levente
>
> On Wed, 21 Aug 2019, Marcel Taeumel wrote:
>
>> #isSimpleSetter :-)
>> Best,
>> Marcel
>>
>>      Am 20.08.2019 21:33:47 schrieb Levente Uzonyi <[hidden email]>:
>>
>>      On Tue, 20 Aug 2019, [hidden email] wrote:
>>
>>      > I finally came around to finish this. Please find attached a changeset which:
>>      > - deprecates #asMutator and removes #isMutator
>>
>>      What will be the replacement for #asMutator?
>>
>>      Levente
>>
>>      > - refactors existing calls to #asSimpleSetter
>>      > - moves #as*Setter to the category System-Support
>>      >
>>      > Depending on further comments I would merge these in the next days/weeks.
>>      >
>>      > 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 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 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 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 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--
>>      >>
>>      > ["mutatorAndSetter.1.cs"]
>>
>



12