Re: [Newbies] Re: A Question of Style
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: VendorpriceAt: 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 ___ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
[Newbies] Re: A Question of Style
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: VendorpriceAt: 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 ___ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
[Newbies] Re: A Question of Style
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: VendorpriceOf: aSymbol Now, to make the setter method, I have followed this pattern: VendorpriceOf: 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: VendorpriceAt: 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: VendorsetPriceOf: 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
