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