properties

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> On Mon, 27 Jul 2009 18:37:01 -0400, Andrei Alexandrescu 
>> ... with zero arguments.
> 
> No, callable types period.  Note that this does not compile:
> 
> class A
> {
>     int delegate(int foo) wyda()
>     {
>         return delegate int(int foo) { return foo;};
>     }
> }
> 
> 
> int main(string[] args)
> {
>     auto a = new A;
>     auto b = a.wyda(5); // line 14
>     auto c = a.wyda()(5);
>     return 1;
> }
> 
> [steves at steveslaptop files]$ dmd testme.d
> testme.d(14): Error: function testme.A.wyda () does not match parameter 
> types (int)
> testme.d(14): Error: expected 0 arguments, not 1
> 
> commenting out line 14 compiles.

Ok, thanks.

>>> 3. A getter can be defined in the opGet_X() form, and then using X() 
>>> will be the eqivalent of opGet_X()().
>>>  There are small implications to leaving the existing getter syntax.  
>>> Namely one can call a function not intended to be a getter in a 
>>> property-like syntax, resulting in less-than-obvious code.
>>
>> This I don't agree with. I am very happy that I define popFront() as a 
>> method and then call it without parens.
> 
> Knowing that you can call functions without parens, seeing code like:
> 
> r.popFront;
> 
> it's obvious that popFront is a function, not a property.
> 
> But, do you agree that this code looks less-than-obvious?
> 
> auto x = flush;
> 
> is flush a flag saying flushing should occur?  is it a function that 
> flushes something, and returns the success?  I agree that the bizarre 
> factor is not as bad as with setters, but it's still not as 
> self-explanatory as if you know that something without parens must be a 
> property for the compiler to accept it.

I think inferring meaning from the presence or absence of "()" is rather 
dicey.

> Let's separate this problem into two sections:
> 
> 1. do we have to hint to the compiler that a function is a property or not?
> 
> I think we do, otherwise, we have the strange setter anomalies, and the 
> inability to return delegates from getters.

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


Andrei