On Tue, 28 Jul 2009 11:11:09 -0400, Andrei Alexandrescu
<[email protected]> wrote:
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.
No, you're saying inferring meaning from parentheses is not a good idea.
I think it's the same thing as saying that inferring the meaning from a
function/field name is not a good idea (just in a more sarcastic way...).
When you see parentheses, you infer function. When you don't you infer
field/property. Note that I'm not just pulling this out of a hat, it's
the way people already think, you should acknowledge that.
As one other person stated, they thought empty() emptied a range.
Well it doesn't.
Exactly, so why do you think he thought that? Let's take someone who's
used a language that uses () do denote a function, and no parens to denote
a field (there are a few of them out there). Would that person ever think
that
x.empty;
means "empty the contents of x"? The answer is no, not ever. Whether you
like it or not or think it's dicey or not PEOPLE WILL INFER MEANING FROM
PARENTHESES. I even do it, even though I *know* that it's dicey. I hate
having to look up usages of things that make no sense because I have no
idea what the code is doing. It's so much better when the meaning is
clear from the code itself.
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.
And for years, there have been complaints about it. This will
continuously be a thorn in the side of D adoption until it is resolved.
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
I'll give you that one, but that's an uncommon "because we can" case.
and also read-only properties, which also don't behave like fields.
Ever heard of readonly fields? Yes, they exist in C#. Besides, that's
one of the benefits of properties, you can do things that you can't do
with fields, otherwise why have them?
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.
No, they did it to *force* you to write a.foo instead of a.foo(), to make
it more defined that foo is a field-like entity. There's a subtle, yet
very important difference. They saw the implementation of properties in
Java as a good thing, but Java relied on a social standard that a method
that begins with get is a getter, a method that begins with set is a
setter, and a method that begins with is is a boolean. C# provides a
better way to convey that contract via properties.
D's implementation looks to me like a quick hack so D can say "look, we
have properties!" They don't provide any of the interface benefits that
true properties do. Might as well go back to Java style, where you have
to name your properties getX, setX or isX. But now, normal functions are
corrupted with the ability to use them as properties.
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.
Lovely. Force the developer to rename his functions because D is too weak
to allow defining a correct interface. You didn't even address the select
example, I think that's a very compelling example of something that breaks
your rule.
My point is that your rule only works if you write code in a certain way,
and I don't think that should be a determination of whether something is a
property or not by the compiler, because the naming of functions is
supposed to be up to the developer, not the spec. It's like a prejudice
against certain coding styles without any good reason.
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?
Yes they do. It makes them behave like a variant field.
e.g.
x.timeout = 5.5; // set timeout to 5.5 seconds
x.timeout = TimeSpan.seconds(5); // set timeout to 5 seconds exactly
And what about getters for delegates? That problem is still unresolved by
your rule.
-Steve
