@property

[Steven Schveighoffer]

On Thu, 24 Jun 2010 16:21:37 -0400, Pelle <pelle.mansson at gmail.com> wrote:

> As heard around these parts, a lot of people want property-style  
> function calls to require the function to be declared with @property,  
> like this:
>
> @property foo(); //getter
> @property foo(int); //setter
>
> foo; //getter
> foo = 13; //setter
>
> While this seems quite reasonable, in practice I and others feel this  
> leads to confusion, especially the getter part. Mostly when the getter  
> has no setter counterpart. D also lets us call no-argument functions  
> without parentheses today, so for this to happen a lot of code needs to  
> change.

How is this confusing?  It's a read-only property.  They are used in  
countless design patterns.

Furthermore, how will allowing any no-arg function to be called without  
parentheses *not* lead to confusion?

e.g.

struct File
{
    bool open() {...}
}

File f;

if(f.open) // looks to me like a property saying whether f is open
if(f.open()) // looks to me like a function opening f.

Like it or not, the parentheses are part of the name of the  
function/property, and to not be able to control whether parens are used  
as an author of said function/property leaves me to answer unending  
requests for changes to the API, such as "why don't you change open to  
openFile to make it clear that it's a function."  Hey, look,  we're back  
to Java's getX and setX, but in reverse!  Wheeee!

With @property, I don't have to do that, because it's very obvious that  
since open requires parentheses, it is effecting an action on f.

>
> My suggestion is as follows; require @property for single-argument  
> setters *only*. Make the silly writeln = 13; go away, but keep the "a b  
> c".split;. This way, there can be no confusion about @property, and most  
> code will go unchanged.

@property is much better than the current situation, even for getters.   
C#, python, I'm sure other languages, have worked fine for years with  
explicit properties, this debate is non-existent there.

In a couple months after @property has been enforcing the parens rule,  
nobody will think about this debate any more.  The only pain is in undoing  
the hack that is D's current properties.

-Steve