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]!
On Thu, Mar 21, 2019 at 1:03 PM Chris Muller asqueaker@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@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]!
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@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@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]!
-- _,,,^..^,,,_ best, Eliot --000000000000004a690584a05ffa--
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 asqueaker@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@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]!
-- _,,,^..^,,,_ best, Eliot --000000000000004a690584a05ffa--
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 asqueaker@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@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]!
-- _,,,^..^,,,_ best, Eliot --000000000000004a690584a05ffa--
["mutatorAndSetter.1.cs"]
On 20.08.2019, at 17:51, patrick.rein@hpi.uni-potsdam.de patrick.rein@hpi.uni-potsdam.de 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 asqueaker@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@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:
-- _,,,^..^,,,_ best, Eliot --000000000000004a690584a05ffa--
["mutatorAndSetter.1.cs"]
On Tue, 20 Aug 2019, patrick.rein@hpi.uni-potsdam.de 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 asqueaker@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@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]! > >
-- _,,,^..^,,,_ best, Eliot --000000000000004a690584a05ffa--
["mutatorAndSetter.1.cs"]
#isSimpleSetter :-)
Best, Marcel Am 20.08.2019 21:33:47 schrieb Levente Uzonyi leves@caesar.elte.hu: On Tue, 20 Aug 2019, patrick.rein@hpi.uni-potsdam.de 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"]
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 <leves@caesar.elte.hu>: On Tue, 20 Aug 2019, patrick.rein@hpi.uni-potsdam.de 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"]
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 <leves@caesar.elte.hu>: On Tue, 20 Aug 2019, patrick.rein@hpi.uni-potsdam.de 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"]
Hi Patrick,
On Wed, 21 Aug 2019, patrick.rein@hpi.uni-potsdam.de wrote:
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?
I just checked the change set. It looks good to me. So, no, it's not worth to keep #'' asSimpleSetter = #':' in my opinion.
Levente
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 <leves@caesar.elte.hu>: On Tue, 20 Aug 2019, patrick.rein@hpi.uni-potsdam.de 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"]
On 21.08.2019, at 11:57, Levente Uzonyi leves@caesar.elte.hu 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 <leves@caesar.elte.hu>: On Tue, 20 Aug 2019, patrick.rein@hpi.uni-potsdam.de 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"]
On Wed, 21 Aug 2019, Tobias Pape wrote:
On 21.08.2019, at 11:57, Levente Uzonyi leves@caesar.elte.hu 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.
You don't want to concatenate strings here, but to append a character to the end of a string. And that's exactly what #copyWith: does. I see no reason not to keep the optimized version. And that's what you +1'd above, isn't it?
Levente
Levente
On Wed, 21 Aug 2019, Marcel Taeumel wrote:
#isSimpleSetter :-) Best, Marcel
Am 20.08.2019 21:33:47 schrieb Levente Uzonyi <leves@caesar.elte.hu>: On Tue, 20 Aug 2019, patrick.rein@hpi.uni-potsdam.de 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"]
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Eliot Miranda -
Levente Uzonyi -
Marcel Taeumel -
patrick.rein＠hpi.uni-potsdam.de -
Tobias Pape