On Mon, 03 Aug 2009 11:03:54 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Steven Schveighoffer wrote:
On Mon, 03 Aug 2009 10:25:02 -0400, Michiel Helvensteijn
<m.helvensteijn.rem...@gmail.com> wrote:
Steven Schveighoffer wrote:
So the poster who started this trail of the thread is assuming that
t.property.get()
identifies the property getter directly. But what if the return type
of
t.property.get() contains a method get()? Since t.property is an
alis for
t.property.get(), Should t.property.get() map to:
...
That is the ambiguity.
I myself see great value in the ability to access the getter and setter
functions directly. But because of the ambiguity you described, this is
problematic for D.
Andrei sees 'get' and 'set' as nothing more than declaration-side
indications of the getter and setter. Not real functions. In that
case, the
ambiguity doesn't exist.
To alleviate possible confusion, it has been suggested that a space be
used,
not a dot, between the name of the property and get/set in the
declaration.
So your answer is, there is no ambiguity because it's not possible to
access the getter/setter directly? That poses a problem for existing
code which uses delegates to such functions. I'm not sure we want to
lose that ability.
-Steve
Now that I think of it, even if properties don't readily return
delegates, they are trivially easy to obtain:
class A
{
... define property foo with whatever syntax ...
}
unittest
{
auto a = new A;
auto getter = () { return a.foo; }
auto setter = (int x) { a.foo = x; }
setter(5);
writeln(getter());
}
I actually compiled and ran that with foo defined as a regular field.
Yes, that works. Now make it so I don't have to go through 2 function
calls :)
But the few times that you need a delegate to a getter/setter probably
makes this kludge a valid solution. It might even be possible to make a
template, like:
PropertyDelegate!(T...) delegateOf(a.foo)
One thing I dislike about D sometimes is how it forces me to go through
extra layers to make the syntax valid, when a direct route is clearly
possible. Yes, I know it doesn't add too much bloat/overhead, but it is
supposed to be a systems language after all...
-Steve
