A provocative naming idea for "setter" methods

[Brian Rice]

On Sep 20, 2005, at 7:14 AM, Lendvai Attila wrote:

> I've got a little concern, tough: it's a base idea in Slate that
> everything is based on uniform message sends. Consider the situation
> where you have some old code in which you decide to replace a simple
> slot-value+accessors with some complex get/set method implementations?
> Then the new setter naming convention would _suggest_ that the method
> called is a simple value setter, even tough it has been replaced with
> something more complex method (which will probably still set some slot
> value(s), but...).

Well, we /have/ been talking about accessors, really, not  
atSlotNamed:/atSlotNamed:put:, and we can already override those. I  
see what you're saying about the intuitive suggestion to the reader,  
but I don't think it'll be a problem once it's understood.

> Unfortunately I don't have a good real world example for this. I just
> know that I like the idea that in Slate I'm free to replace a
> slot+accessors with something more complex without changing the
> interface of the object.

Well, there are various examples of mutator-overriding, where we  
might want to notify observers (which we have code for), or have  
other side-effects or do copy-on-write which would alter the  
semantics even more.

--
-Brian