properties

[Andrei Alexandrescu]

Michel Fortin wrote:
> 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?

It all follows normal language rules. That's what I like about rewrites 
(lowerings): they allow you to reason about a new mini-feature (that in 
this case is absolutely nothing beyond a minor syntactic convenience) in 
terms of the rest of the language.

> 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.

I think the rules are very obvious.

> 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.

It doesn't solve the problem with a getter that returns a delegate. 
People who want to return delegates must use an extra pair of parens.

> 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 wouldn't want to hurt the majority of my code for an obscure case. I 
do agree I'd rather not have an obscure case in the first place.

> 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.

That would work. Many things would work.


Andrei