A Question of Style

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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

I like the second one; it explains your intention much better.

Ron


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

El 3/30/07 2:58 PM, "Ralph Johnson" <[hidden email]> 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


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Fri, 30 Mar 2007 10:12:15 -0800, Edgar J. De Cleene  
<[hidden email]> wrote:

> El 3/30/07 2:58 PM, "Ralph Johnson" <[hidden email]> 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.
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Fri, 30 Mar 2007 18:22:22 +0200, Tim Johnson 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 :)

/Klaus


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Yes, priceAt:put: is better than setPriceOf:to:

-Ralph
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Yes indeed!

Ron


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Sat, 31 Mar 2007 19:08:08 +0200, you wrote:
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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On 4/1/07, Klaus D. Witzel <[hidden email]> 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
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

+ 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:


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners