Steven Schveighoffer wrote:
On Sun, 02 Aug 2009 03:43:43 -0400, Walter Bright
<[email protected]> wrote:
Having optional parentheses does lead to unresolvable ambiguities. How
much of a problem that really is is debatable, but let's assume it
should be resolved. To resolve it, a property must be distinguishable
from a regular function.
One way is to simply add a "property" attribute keyword:
property bool empty() { ... }
property void empty(bool b) { ... }
The problem is that:
1. there are a lot of keywords already
2. keywords are global things
The alternative is to have a unique syntax for properties. Ideally,
the syntax should be intuitive and mimic its use. After much fiddling,
and based on n.g. suggestions, Andrei and I penciled in:
bool empty { ... }
void empty=(bool b) { ... }
The only problem is when a declaration but not definition is desired:
bool empty;
but oops! That defines a field. So we came up with essentially a hack:
bool empty{}
i.e. the {} means the getter is declared, but defined elsewhere.
What do you think?
I have to confess, I thought I wrote my last reply for property debate...
As for the proposed syntax, the setter syntax looks acceptable, but I
don't really like the getter syntax.
I can't think of a really good analagous setter symbol to =. Some of
the other syntaxes I've seen show promise such as:
bool empty.get { ... }
void empty.set(bool b) {...}
One thing to consider is if it should be possible to take a delegate of
a property setter or getter, how do you identify the property function
itself? This solution provides an easy way:
&empty.get
&empty.set
The only issue with this is if the type returned from the getter
actually defines a get field or method. While having a method called
get might be a likely possibility, having that on a type that is likely
to be returned as a property is probably unlikely. There is of course a
workaround:
empty.get().get();
-or-
auto tmp = empty;
tmp.get();
to call the underlying method.
Another option is to name the getter and setter something less likely to
be used, such as opGet/opSet or _get/_set. Finally, you could have a
renaming rule that would allow access to the function. For example
empty.get translates to get_empty(), so if you called get_empty() it
would call the getter. C# does something like this.
Yet another option is to involve some sort of punctuation, e.g.:
empty.get(); // call the returned type's get function
&em...@get; // delegate to the getter.
Note that the only one of these that makes a lot of sense for the
property keyword solution (or your solution) is the renaming empty to
get_empty().
I'm glad to see that this might actually be addressed.
-Steve
That's one place where rewriting shines :o). There's no need to even
think of how to do it when properties work as get_empty() and
set_empty(bool) - the means are already in the language.
Andrei
