On Tue, 28 Jul 2009 14:19:49 -0400, Andrei Alexandrescu
<[email protected]> wrote:
Bill Baxter wrote:
On Tue, Jul 28, 2009 at 10:20 AM, Steven
Schveighoffer<[email protected]> wrote:
On Tue, 28 Jul 2009 12:30:00 -0400, Andrei Alexandrescu
<[email protected]> wrote:
Steven Schveighoffer wrote:
What if the compiler allowed you to call functions as long as what you
typed was an unambiguous prefix of the function name
why don't we have a
wonderful time-saving feature like this? Because it would be a
nightmare to
read.
...
So now C# has two ways of providing a readonly field. Doesn't quite
look
like an example to follow.
Just like D!
Yes, that's right. readonly is analogous to const.
...
That's what I'm saying: if it could do anything, at least don't
pretend
it's anything special. It's a function!
...
So would you argue that C# or D with operator overloading isn't
better because operators are just functions, why call them something
else?
Bravo! Fine, rational arguments, Steve.
I don't think it's a good argument. Operators are functions with a
specific syntax, is all. D is not even pretending any different: it
simply rewrites the usual syntax into function calls. We should do the
same with properties.
I was using this as an example of how your arguments against property
definitions sound to me.
Operators are not the same as properties -- the definition syntax is the
same word, every time. So once you learn that the non-english term opAdd
defines what happens when you type +, you can repeatedly use that
knowledge.
For example, I know that for the following code:
x + y;
I know this means "add x to y," and it might call opAdd or it might be a
builtin operation, I don't care, but I know it means to add. It might
even execute arbitrary code that does something completely different, but
it's not my fault because the author didn't follow the standard convention.
I don't have to look it up, or know what the author of object x meant, the
meaning is not subject to debate or English ambiguity.
However, when I see:
x.empty;
I can't tell what is implied here. empty could be a field or property, in
which case the user made a logic error, or it could be a function that
empties x, or it could be some code that does something completely
different. I assume the author is going to name his functions after what
they do, similarly to how opAdd should be used for addition. English is
not precise, and can have multiple meanings for the same exact word.
Context is important.
But it gets worse. Now I see this:
y.empty;
Oh, I learned what empty meant before, right? WRONG! y could be written
by a completely different author, and could have the opposite meaning.
The problem is, you can't come up with a non-prejudiced definition of what
empty should always mean, because the English term itself is ambiguous.
All you can do is use conventions that can be defined, such as () performs
an action, but lack of () denotes a field, or come up with java-like
conventions (e.g. doXxx means it's a function). So if I can couple the
term empty with the context of lack of parentheses meaning field, I can
deduce the meaning of empty *without looking it up*. The advantage is not
having to look up what code means because the author did a good job of
naming the function/property. This is currently impossible with D.
Coming up with bizarre rules that require pairs of functions doesn't make
things any easier. I still have to look up the usage of empty every time
I encounter a new usage of it, because it could mean one of two things.
-Steve
