properties

[Steven Schveighoffer]

On Tue, 28 Jul 2009 10:16:16 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

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

Really?  Then why name your functions things like empty, why not ex245, to  
make them look it up, making *sure* they know what the meaning is before  
they use it.  As one other person stated, they thought empty() emptied a  
range.

Being able to read code and understand what it means without resorting to  
documentation is the sign of a good choice of symbol names.  The presence  
or absence of parens is a hard-coded accepted meaning of field vs.  
function.  Properties build on this notion by making a virtual field that  
actually resolves to a function (but behaves like a field, and this is an  
important accepted meaning).  However, D does not allow intuitive names to  
be paired with the intuitive meaning of the presense or absence of parens,  
because you can't enforce it!  Remember my example with TimeSpans?  People  
will infer meaning from the presense or absense of parens whether you  
think it's a good idea or not.  You will never get away from it.

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

This is a band-aid fix, easily broken.

int select(int timeoutMS = -1); // method on a socket, for example

Hell, even my TimeSpan problem would still fail.

Also you are forgoing the ability to have overloaded setters, which could  
be useful.  Not to mention getters for delegates.

-Steve