@property - take it behind the woodshed and shoot it?

[Adam Wilson]

On Thu, 24 Jan 2013 00:34:42 -0800, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> This has turned into a monster. We've taken 2 or 3 wrong turns somewhere.
>
> Perhaps we should revert to a simple set of rules.
>
> 1. Empty parens are optional. If there is an ambiguity with the return  
> value taking (), the () go on the return value.
>
> 2. the:
>     f = g
> rewrite to:
>     f(g)
> only happens if f is a function that only has overloads for () and (one  
> argument). No variadics.
>
> 3. Parens are required for calling delegates or function pointers.
>
> 4. No more @property.


I don't see what is so bloody difficult about this. C# has very good very  
clear guidelines and syntax enforcement. I think it's a case of D trying  
to be TO flexible.

In C#:
Function Calls have Parens. Period.
Property Calls do NOT have Parens. Period.
It's quick, clean, and easy to parse.
C# has it's own issue with verbosity around declaration of properties, but  
for a property consumer the rules are trivial. That's the whole point of  
properties.
Also note, that C# has the 'property' keyword to enforce proper syntax.

In D:
Optional parens for everyone!
Parsing nightmare for all!

I also want to reiterate a point I've seen on this thread. Parens on  
properties is a very C programmer thing. What is the net effect of forcing  
properties to have parens? I have to type two more shift-characters to  
satisfy the compiler because we couldn't be arsed to get the current  
implementation right. Ehm. That's not how you make a case to newbie...  
Banish that idea, permanently!

Let's consider what a property really is. It's a data encapsulation tool.  
They allow us to expose object internal data in a safe way. Nuking the  
idea is a step backwards.

While I get that C++ users would immediately be comfortable with the  
ambiguities of not having a distinct property mechanism, you're going to  
have to explain to all the C#/Java users the as long as you create the  
correct functions the compiler will automagically figure out it's a  
property.

And consider that in not all cases do I want int GetMyData() { } to be  
callable without parens as you are suggesting here. Although I provide no  
demo implementation, imagine that this is a non-trivial function that  
modifies other data in the object. (Although properties can do this in C#,  
it runs against guidelines.) Now some innocent programmer calls my  
function as a property not realizing what is really going on and BOOM! He  
just wrote himself a bug. And yes, i've written code like this before. And  
before the academics pile on me for it. My job is to write code that gets  
the job done, being academically correct is for when all other  
requirements have been satisfied. In the real world, we don't have the  
luxury of spending a day to make our code ideal.

One of the principles of encapsulated data is that accessing the data has  
zero side-effects. This change makes what is happening ambiguous to the  
user of the property/function. Ambiguity is bad and will NOT solve our  
problems.

My vote: Fix @property. Dropping it will create even more problems and not  
likely fix many of the current ones. You never solve problems by making  
the code more ambiguous.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/