properties

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> The "getter" notation that currently exists only has a few minor 
> problems.  The most major of those problems is if the return value is a 
> callable type, such as a delegate, you can't easily perform the call on 
> the returned value.

Thanks for a very lucid analysis! So let me give an example:

class A
{
     int delegate() wyda()
     {
         return delegate int() { return 5; };
     }
}

void main(string[] args)
{
     auto a = new A;
     auto b = a.wyda;
     writeln(typeof(b).stringof);
     auto c = a.wyda();
     writeln(typeof(c).stringof);
     auto d = a.wyda()();
     writeln(typeof(d).stringof);
     auto e = &a.wyda;
     writeln(typeof(e).stringof);
}

This program prints:

int delegate()
int delegate()
int
int delegate() delegate()

I agree that that's an issue. One can't currently implement 
transparently a property that returns a delegate taking no arguments. 
There's an extra () needed.

>  Being that it isn't very bad for the getter 
> property, would it make sense to leave that functionality?  That is:
> 
> 1. A setter must be defined in the opSet_X(int x) form
> 2. A getter can be a function with no required arguments, but this 
> getter should not return callable types

... with zero arguments.

> 3. A getter can be defined in the opGet_X() form, and then using X() 
> will be the eqivalent of opGet_X()().
> 
> There are small implications to leaving the existing getter syntax.  
> Namely one can call a function not intended to be a getter in a 
> property-like syntax, resulting in less-than-obvious code.

This I don't agree with. I am very happy that I define popFront() as a 
method and then call it without parens.

>  Also, this 
> distinction will be very hard to explain to newbies ("how come a getter 
> is defined as x(), but a setter has to be opSet_x(...)?).

I don't see that as a problem. You just explain that the trailing () is 
not necessary, and then you tell them to define opSet_x if they want to 
enable obj.x = y.

> The more I look at it, the more I like the keyword solution.  I do find 
> the C#-like syntax which groups properties together appealing, but I 
> think you only absolutely need that if you are going to have 
> context-keywords, which I DON'T think we need.  I do find the whole 
> construct of C# properties tedious to type.
> 
> With a keyword attribute, you could even group your properties together 
> to save on typing/ugliness:
> 
> property
> {
>    int x() {}
>    void x(int n) {}
>    bool empty() {}
> }

Not a fan, but this would work. I just don't see why I need to go 
through with it.


Andrei