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.
