properties

[Michel Fortin]

On 2009-07-28 11:37:05 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> Michel Fortin wrote:
>> On 2009-07-28 10:16:16 -0400, Andrei Alexandrescu 
>> <SeeWebsiteForEmail at erdani.org> said:
>> 
>>> Well I don't think so. To repeat what I wrote elsethread: foo = bar is 
>>> rewritten into foo(bar) if and only if auto __x = foo, __x = bar works. 
>>> This means, a setter only works if there's a corresponding getter. 
>>> (Write-only properties be damned.)
>> 
>> This may lead to strange issues if both the setter and the getter don't 
>> have the same protection attribute, or purity, or constness of 
>> arguments.
>> 
>> For instance:
>> 
>>     protected void foo(Object o);
>>     public pure const const(Object) foo();
>> 
>> Here, you can assign to foo using the property syntax only from a 
>> non-pure functions of this class or a derived classes and when the 
>> value you're assinging is a const(Object). Elsewhere, you can only 
>> assign using the function syntax. Anything else would break "auto __x = 
>> foo, __x = bar".
> 
> Well I chose the rule that makes bar look and feel as much as an 
> assignable value as possible. The rule could be relaxed (e.g. by 
> dropping qualifiers), but that means we're departing from assignable 
> value lookalike.

Also, what if a derived class implements a getter while the base class 
only has a setter. Does that mean that only the derived class can use 
the property syntax on the base class' setter?

What I don't like about that proposal is that that how to call a setter 
is bound to the existence of another function in the same scope using 
pretty non-obvious rules. Also, it doesn't solve the problem of the 
getter that returns a delegate since you can continue using the 
function notation with properties and you can continue to call 
functions with no parenthesis.

While I like too being able to call functions with no argument by 
skipping the tailing parenthesis, I'd easily give up on that if it 
means I can get a language with less ambiguities.

I also happen to agree with Walter and you that it wouldn't be so great 
to just decorate functions with a keyword to give them a different 
syntax. I've propsed earlier a namespace-like syntax where you can have 
functions like "foo.opAssign" inside a class (or anywhere really) that 
you can call with "foo = x", unifying properties with operator 
overloading.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/