A provocative naming idea for "setter" methods

[Peter van Rooijen]

Brian T. Rice wrote:
> Diego Fernandez <diegof79 at gmail.com> said:
>>Why just don't use categories to avoid confusion? 
>>If you have a "handle:" setter, use a proper method categorization
> 
>> (like "accessing"). 
>>I think that this simple solution is enough to avoid confusion.
> 
> 
> I'm sorry, but you missed my point about how this works. The
> /sender/ of the message is who gets confused, not the receiver.
> Without perfect type inference, you won't know what method
> implements a given message, so its method category is unavailable.
> Do you see the problem? I'd rather have the intention in the name
> than just in the implementation (or its annotations).

What Brian says is central: it is about revealing the intent of the send.

There is a real problem with expressing intent in imperative computer 
programs.

And there are at least two sides to this: expressing the intent of 
methods (what the method body does), and expressing the intent of sends.

Representing the intent of methods is an area that has been explored 
extensively in the language Eiffel, which allows the addition of 
preconditions and postconditions to methods, with the ability to have 
the assertions checked (Eiffel also supports a few other types of 
assertions but those are less relevant here).

Representing the intent of sends is quite a different animal. It is 
regularly seen that naming conventions for identifiers are used to 
represent intent. We see this a lot in Lisps with things such as ? ! p 
*foo* that are used in identifiers. In Java we see conventions like 
getFoo() and setFoo().

I get the impression that Brian is not looking for a mere convention, 
but wants something more. He might also not be opposed to having a 
'setter' do something else apart from setting the slot, perhaps so long 
as it does in effect set the slot. Brian will be able to comment.

This could be quite useful.

An idea that might be helpful is to adopt a special message send form 
that carries an implied postcondition, like so:

myObject foo= theNewValue

which would carry an implied postcondition as follows:

myObject foo= theNewValue {Must theNewValue = myObject foo}

which intends to say that whatever foo: does, the result of myObject foo 
must be theNewValue at the end of the instruction.

If checking of this implied postcondition can be turned on, this would 
seem to provide the (presumably sought) advantage that the reader of 
myObject foo= theNewValue knows something about what is the case after 
the message is sent.

If he has the checking turned on, he even has a guarantee that it will 
be so.

As an additional advantage, if the method foo: is not found for that 
message send, the message could be executed by simply setting the slot 
value. Thus the implied precondition is satisfied (usually, depending on 
how a possible foo method might be defined), and the need to write 
simple setters is removed.

Well, this is an idea for a system and mechanism that would allow 
gaining experience with formalizing intent in message send instructions, 
to see if this kind of thing seems to be worth the trouble.

Please note that I am not a Slater, so my Slate syntax might be off. I 
hope it is still clear, though :-).

Regards,

Peter