Hi,
I know the rules for naming accessor and setter methods. But what do I do when the accessor method needs a parameter? I'll try to provide an example.
A vendor sells an item called #apple. If I want to get the vendor's price for that #apple, I use a method such as the following:
Vendor>>priceOf: aSymbol
Now, to make the setter method, I have followed this pattern:
Vendor>>priceOf: aSymbol is: newPrice
Does this follow traditional patterns? I'll admit I have read the first half of "Smalltalk with Style" but not the second. Should I instead make the setter method look like this:
Vendor>>setPriceOf: aSymbol to: newPrice
?
Thanks, Tim
[PS - Thanks to everyone who has been helping me on here lately, I have been lax in responding. You all bring up some good ideas and tips.]
I like the second one; it explains your intention much better.
Ron
From: Tim Johnson
Hi,
I know the rules for naming accessor and setter methods. But what do I do when the accessor method needs a parameter? I'll try to provide an example.
A vendor sells an item called #apple. If I want to get the vendor's price for that #apple, I use a method such as the following:
Vendor>>priceOf: aSymbol
Now, to make the setter method, I have followed this pattern:
Vendor>>priceOf: aSymbol is: newPrice
Does this follow traditional patterns? I'll admit I have read the first half of "Smalltalk with Style" but not the second. Should I instead make the setter method look like this:
Vendor>>setPriceOf: aSymbol to: newPrice
?
Thanks, Tim
[PS - Thanks to everyone who has been helping me on here lately, I have been lax in responding. You all bring up some good ideas and tips.]
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
setPriceOf:to: is better than priceOf:is: because it is a command. In general, messages that have side effects should be commands.
Setting accessor methods are a time-honored exception.
-Ralph
El 3/30/07 2:58 PM, "Ralph Johnson" johnson@cs.uiuc.edu escribió:
Setting accessor methods are a time-honored exception.
Could expand ? Are you saying what if we have foo should have setfoo: and getfoo: ? Is that is the case is a simple implementation...
Edgar
On Fri, 30 Mar 2007 10:12:15 -0800, Edgar J. De Cleene edgardec2001@yahoo.com.ar wrote:
El 3/30/07 2:58 PM, "Ralph Johnson" johnson@cs.uiuc.edu escribió:
Setting accessor methods are a time-honored exception.
Could expand ? Are you saying what if we have foo should have setfoo: and getfoo: ? Is that is the case is a simple implementation...
I believe he's saying: By the logic of using "set" to indicate setting a value, you should have "setFoo:" but when its an accessor method, using just "foo:" is the time-honored exception.
On Fri, 30 Mar 2007 18:22:22 +0200, Tim Johnson wrote:
Hi,
I know the rules for naming accessor and setter methods. But what do I do when the accessor method needs a parameter? I'll try to provide an example.
A vendor sells an item called #apple. If I want to get the vendor's price for that #apple, I use a method such as the following:
Vendor>>priceOf: aSymbol
Now, to make the setter method, I have followed this pattern:
Vendor>>priceOf: aSymbol is: newPrice
I've seen the suggestions in other responses to this and I don't like them.
Calling "everything" a setter/getter seems to be J-zeitgeist but, what you have here is a collection of prices, indexed by a symbolic key, rooted at instances of Vendor.
Translated to Smalltalk language this is a variant of #at:put:
Vendor>>priceAt: aSymbol put: newPrice
Even more Smalltalk-ish, you'd have
aVendor pricebook at: aSymbol put: newPrice
People with an education in Smalltalk will immediately understand what's happening when seeing a piece of your code which sends #priceAt:put:, even in the absence of class comments :)
/Klaus
Does this follow traditional patterns? I'll admit I have read the first half of "Smalltalk with Style" but not the second. Should I instead make the setter method look like this:
Vendor>>setPriceOf: aSymbol to: newPrice
?
Thanks, Tim
[PS - Thanks to everyone who has been helping me on here lately, I have been lax in responding. You all bring up some good ideas and tips.]
I've seen the suggestions in other responses to this and I don't like them.
Calling "everything" a setter/getter seems to be J-zeitgeist but, what you have here is a collection of prices, indexed by a symbolic key, rooted at instances of Vendor.
Translated to Smalltalk language this is a variant of #at:put:
Vendor>>priceAt: aSymbol put: newPrice
Even more Smalltalk-ish, you'd have
aVendor pricebook at: aSymbol put: newPrice
People with an education in Smalltalk will immediately understand what's happening when seeing a piece of your code which sends #priceAt:put:, even in the absence of class comments :)
Something I read in Smalltalk With Style, though, says that you should hide the implementation details. Your method names should not refer to the data structures behind them. Even though my Vendor's pricelist is a Dictionary, I do not need to expose that implementation to the user of Vendor. Smalltalk With Style makes this very clear. It definitely prefers that I communicate with Vendor in the language of a Vendor, and not in the language of a Dictionary.
It is similar to if I went to a GroceryStore. I would not log in to their SuperMainframe5000 and type in SQL code to query the price of an apple. I would ask their sales representative, "how much is an apple?"
Also, I am not a Java user so I am not trying to Java-tize Squeak :)
Thanks, Tim
On Sat, 31 Mar 2007 19:08:08 +0200, you wrote:
I've seen the suggestions in other responses to this and I don't like them.
Calling "everything" a setter/getter seems to be J-zeitgeist but, what you have here is a collection of prices, indexed by a symbolic key, rooted at instances of Vendor.
Translated to Smalltalk language this is a variant of #at:put:
Vendor>>priceAt: aSymbol put: newPrice
Even more Smalltalk-ish, you'd have
aVendor pricebook at: aSymbol put: newPrice
People with an education in Smalltalk will immediately understand what's happening when seeing a piece of your code which sends #priceAt:put:, even in the absence of class comments :)
Something I read in Smalltalk With Style, though, says that you should hide the implementation details.
This is satisfied by #priceAt:put: since nobody knows how you do that.
Some analogies: #attributeAt: #categoryAt: #childAt: #colorAt: #digitAt: #fontAt: #lineAt: #sourceMethodAt: #compiledMethodAt: (the list is much longer).
Your method names should not refer to the data structures behind them.
Without doubt the pricebook is a collection. And the traditional access protocol, which everybody who's familiar with Smalltalk is aware of, it some variant of #at:put:.
This Smalltalk style maximizes the convenience of the reader / maintainer / re-user / novice / convert / etc, of course.
Even though my Vendor's pricelist is a Dictionary,
I don't care that it's a Dictionary, as long as the pricebook is a collection (more than *one* thing and accessible by some sort of key).
I do not need to expose that implementation to the user of Vendor.
Since #at:put: does not expose any implementation detail, #priceAt:put: does not expose its secrets either.
Smalltalk With Style makes this very clear. It definitely prefers that I communicate with Vendor in the language of a Vendor, and not in the language of a Dictionary.
The #at:put: vocabulary is part of the language of Smalltalk, which is universal and independent of Vendor language. You do not implement Smalltalk in the labguage of Vendor but, the opposite direction is the case. This is inevitable and the language direction is irreversable.
It is similar to if I went to a GroceryStore. I would not log in to their SuperMainframe5000 and type in SQL code to query the price of an apple. I would ask their sales representative, "how much is an apple?"
Comparing SQL to Smalltalk is not appropriate here, since for some form of comparision between apples and oranges both must be on par at least in terms of capabilities, expressibility and usability. SQL lacks all that.
Also, I am not a Java user so I am not trying to Java-tize Squeak :)
Sorry if that was not clear enough: I was talking about the responses :)
/Klaus
Thanks, Tim
On 4/1/07, Klaus D. Witzel klaus.witzel@cobss.com wrote:
Smalltalk With Style makes this very clear. It definitely prefers that I communicate with Vendor in the language of a Vendor, and not in the language of a Dictionary.
The #at:put: vocabulary is part of the language of Smalltalk, which is universal and independent of Vendor language. You do not implement Smalltalk in the labguage of Vendor but, the opposite direction is the case. This is inevitable and the language direction is irreversable.
If I were examining the methods of Vendor, and I saw priceAt: put: then yes, I'd realise that I was witnessing some sort of Dictionary like API, but my two questions would be "at what?" and "what am I putting?". You could probably guess that it wanted an item and a price, but the wording seems to imply it wants the price as the key, and the item as the value. I'd probably have to end up looking at the implementation to make sure which way round it wanted it. If I saw #priceOf:is: or #setPriceOf:to:,it'd be far more obvious what was going on.
To insist on #at:put simply because it's what's used by a Dictionary seems wrong, because it's not the interface to the price book that's in question, it's the interface to the Vendor, and in this case creates an awkward feeling API - much like dogmatic adherence to some English style guides creates awkward sentences (as in the apocryphal Churchill quote: "This is the sort of English up with which I will not put").
Maybe this discussion is a sign that it would make more sense to expose the price book separately, rather than put the price setting messages on the vendor itself? The pricebook would then have #at:put, because it certainly is a collection, and by being a pricebook it's obvious what the key and value should be.
so rather than "aVendor priceOf: #foo is: price" or "aVendor priceAt: #foo put: price", you'd have: "aVendor pricebook at: #foo put: price"
This seems to satisfy both the condition of using the language of the domain, and provides the familiarity of the dictionary interface.
Regards, Stuart
+ 1
and I couldn't have worded it better :)
IHMO (and perhaps only there) an object is allowed to pretend to *also* be something else (aVendor pretends to be aPricebook, in the #priceAt:put: example) *only if* it could effectively take that role.
If not or in doubt: delegate to someone who lives that role [talk small and create great things].
/Klaus
On Sun, 01 Apr 2007 12:05:35 +0200, Stuart Herring wrote:
On 4/1/07, Klaus D. Witzel klaus.witzel@cobss.com wrote:
Smalltalk With Style makes this very clear. It definitely prefers that I communicate with Vendor in the language of a Vendor,
and
not in the language of a Dictionary.
The #at:put: vocabulary is part of the language of Smalltalk, which is universal and independent of Vendor language. You do not implement Smalltalk in the labguage of Vendor but, the opposite direction is the case. This is inevitable and the language direction is irreversable.
If I were examining the methods of Vendor, and I saw priceAt: put: then yes, I'd realise that I was witnessing some sort of Dictionary like API, but my two questions would be "at what?" and "what am I putting?". You could probably guess that it wanted an item and a price, but the wording seems to imply it wants the price as the key, and the item as the value. I'd probably have to end up looking at the implementation to make sure which way round it wanted it. If I saw #priceOf:is: or #setPriceOf:to:,it'd be far more obvious what was going on.
To insist on #at:put simply because it's what's used by a Dictionary seems wrong, because it's not the interface to the price book that's in question, it's the interface to the Vendor, and in this case creates an awkward feeling API - much like dogmatic adherence to some English style guides creates awkward sentences (as in the apocryphal Churchill quote: "This is the sort of English up with which I will not put").
Maybe this discussion is a sign that it would make more sense to expose the price book separately, rather than put the price setting messages on the vendor itself? The pricebook would then have #at:put, because it certainly is a collection, and by being a pricebook it's obvious what the key and value should be.
so rather than "aVendor priceOf: #foo is: price" or "aVendor priceAt: #foo put: price", you'd have: "aVendor pricebook at: #foo put: price"
This seems to satisfy both the condition of using the language of the domain, and provides the familiarity of the dictionary interface.
Regards, Stuart
Yes indeed!
Ron
From: Klaus D. Witzel
On Fri, 30 Mar 2007 18:22:22 +0200, Tim Johnson wrote:
Hi,
I know the rules for naming accessor and setter methods. But what do I do when the accessor method needs a parameter? I'll try to provide an example.
A vendor sells an item called #apple. If I want to get the vendor's price for that #apple, I use a method such as the following:
Vendor>>priceOf: aSymbol
Now, to make the setter method, I have followed this pattern:
Vendor>>priceOf: aSymbol is: newPrice
I've seen the suggestions in other responses to this and I don't like them.
Calling "everything" a setter/getter seems to be J-zeitgeist but, what you have here is a collection of prices, indexed by a symbolic key, rooted at instances of Vendor.
Translated to Smalltalk language this is a variant of #at:put:
Vendor>>priceAt: aSymbol put: newPrice
Even more Smalltalk-ish, you'd have
aVendor pricebook at: aSymbol put: newPrice
People with an education in Smalltalk will immediately understand what's happening when seeing a piece of your code which sends #priceAt:put:, even in the absence of class comments :)
/Klaus
Does this follow traditional patterns? I'll admit I have read the first half of "Smalltalk with Style" but not the second. Should I instead
make
the setter method look like this:
Vendor>>setPriceOf: aSymbol to: newPrice
?
Thanks, Tim
[PS - Thanks to everyone who has been helping me on here lately, I have been lax in responding. You all bring up some good ideas and tips.]
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
beginners@lists.squeakfoundation.org
-
Blake -
Edgar J. De Cleene -
Klaus D. Witzel -
Ralph Johnson -
Ron Teitelbaum -
Stuart Herring -
Tim Johnson