Steven Schveighoffer wrote:
On Tue, 28 Jul 2009 10:16:16 -0400, Andrei Alexandrescu
<[email protected]> 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
