A provocative naming idea for "setter" methods

[Brian T. Rice]

Diego Fernandez <diegof79 at gmail.com> said:

> Brian thanks for your reply!
> 
> Again, the sender of the message won't see that meta-data until it
> > infers the correct type. This also gets a little too close to
> > breaking encapsulation, to have to know too much at compile-time to
> > understand what will happen at run-time. Putting the information
> > that "this sets something" vs. "this acts on the arguments with this
> > verb" is not breaking encapsulation, it's revealing information that
> > makes code clearer.
> 
> 
> Suppose this one implementation of this:
> 
> MyNumberView>>model: aNumber
> textWidget text: (numberFormatter format: aNumber)
> 
> MyNumberView>>model
> [ numberParser parse: textWidget text ] when:
NumberParsingException do:
> [:signal |
> ModelCreationException signalChainedWith: signal
> ]
> 
> You can say, ok this "model:" method is not a mutator per sé
because it
> doesn't change directly any instance variable of MyNumberView (yes
I know i
n
> Slate are slots, and I'm changing the instance of textWidget).
> Then I have another implementation of "MyNumberView" that keeps
the value o
f
> model in an instance variable:
> OtherImplementationOfNumberView>>model: aNumber
> model := aNumber.
> OtherImplementationOfNumberView>>model
> ^model
> 
> Should I use the setter syntax for both?
> (Sorry if my question is too stupid.. maybe it's because I'm a Slate
> beginner)

Yes, that would be part of the idiom, that anything which is not a
verb but a "setter", whether concretely or abstractly, should have a
separate selector-name style.

And "model" is, after all, also a verb that takes a direct object.

--
-Brian