properties

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> 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.

I didn't say not to infer meaning from the name.

> As one other person stated, they thought empty() 
> emptied a range.

Well it doesn't.

> Being able to read code and understand what it means without resorting 
> to documentation is the sign of a good choice of symbol names.

Sure.

> The 
> presence or absence of parens is a hard-coded accepted meaning of field 
> vs. function.

I understand how some people want to derive meaning from obj.foo() 
versus obj.foo. I think they shouldn't in D. I mean D has had for years 
the behavior that you could drop the trailing empty parentheses.

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

Not quite. C# has allocated a language feature for properties. Yet they 
allow you to write write-only properties, which do NOT behave at all 
like fields, and also read-only properties, which also don't behave like 
fields. Guess what - they both behave like functions. So their 
properties are an elaborate mechanism that is actually thoroughly 
unchecked, thus going back to what you could do by calling functions. So 
why the hell did they define the feature in the first place? Oh, for 
allowing people to write a.foo() instead of a.foo. You know what, that's 
a bit disappointing for an entire language feature.

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

Well maybe you could change TimeSpan.

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

Wait, overloaded setters do NOT make the thing behave like a field, but 
you were stating how nice that is a few paragraphs ago! So what is it 
that you think is good?


Andrei