property syntax strawman
Steven Schveighoffer
schveiguy at yahoo.com
Mon Aug 3 08:15:17 PDT 2009
On Mon, 03 Aug 2009 11:03:54 -0400, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> Steven Schveighoffer wrote:
>> On Mon, 03 Aug 2009 10:25:02 -0400, Michiel Helvensteijn
>> <m.helvensteijn.remove at 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
More information about the Digitalmars-d
mailing list