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
_______________________________________________
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners
