properties

[Steven Schveighoffer]

On Tue, 28 Jul 2009 14:19:49 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Bill Baxter wrote:
>> On Tue, Jul 28, 2009 at 10:20 AM, Steven
>> Schveighoffer<schveiguy at yahoo.com> wrote:
>>> On Tue, 28 Jul 2009 12:30:00 -0400, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at erdani.org> 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