@property

[Pelle]

On 06/24/2010 10:45 PM, Steven Schveighoffer wrote:
>
> How is this confusing? It's a read-only property. They are used in
> countless design patterns.
>

The confusion isn't their existence, but rather deciding what is a 
property and what is not.

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

Note that many languages never require parentheses, and they're not 
particularly confused.

>
> 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.

I feel this is a naming issue, not a @property-issue. Is the empty() of 
a range a property? Is the save() a property? It's just up to anyone to 
guess and argue either way.

> @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.

And paren-less function calls have worked fine for years in a bunch of 
other languages. This debate is non-existent there as well.

> 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

The only hack is that calling by assigning works for all single-arg 
functions.