property / getProperty() / setProperty()

[Andrei Alexandrescu]

Michel Fortin wrote:
> I hope this proposal can rally more that divide... let's see.
> 
> Andrei said this in another thread about adding a property keyword in 
> front of functions to make them properties:
> 
>> The problem is that it's all loss, no gain: the callee must make the
>> decision whether the call must be with or without parens, and the caller
>> must obey that decision. There is no guarantee gained, only effort.
> 
> I see your point Andrei: it's little gain to add a syntax that's just a 
> modifier to a function to decide how you must call it.

That's a great summary.

> I also see the point of all those arguing that it's important to be able 
> to distinguish between a property and an action, and that the english 
> laguage is not expressive enough to make that distinction clear in a lot 
> of cases.

I understand that point too.

> I know, I've written programming guidelines[1] and tried very 
> hard to make this problem go away by mandating "is", "has" or a modal 
> verb as a prefix for boolean attributes in the guidelines, only to be 
> stuck with no solution for the "transform" example from Bill Baxter 
> (thread "Properties - another one that gets me") which isn't boolean and 
> for which you can't really add a prefix that makes sense.
> 
> [1]: http://prowiki.org/wiki4d/wiki.cgi?DProgrammingGuidelines

Good point.

> The best simple solution to that property problem I've seen up to now is 
> to define "getProperty" and "setProperty" and have the compiler 
> automatically check for these functions when it encounters the 
> "property" symbol.
> 
> Why do I favor "getThing" and "setThing" over "opGet_thing" and 
> "opSet_thing"? Because the later are ugly. Please don't underestimate 
> aestetics and readability as those are the key to make the language 
> enjoyable to use and what the beginners will judge the language from. 
> Also, the pattern will be pretty familiar to those comming from Java and 
> elsewhere. And finally, for those who don't like having a property 
> syntax, they can ignore properties completely and continue to use the 
> get/set functions directly without making their code ugly.

I also like getThing and setThing more than get_thing and set_thing for 
defining a property called "thing". They both have problems, though: the 
former can't define a property starting with an uppercase letter, and 
the latter can't define a property starting with an underscore. (Symbols 
can't contain two underscores.) Ideas?

> Here's an example:
> 
> ~~~
> int getValue();
> void setValue(int x);
> 
> setValue(1);              /* property: */  value = 1;
> assert(getValue() == 1);  /* property: */  assert(value == 1);
> ~~~
> 
> The problems this syntax should fix are:
> 
> 1. the ambiguity between actions and properties: getValue()/setValue() 
> are functions and  thus actions named with verbs ("get" and "set"), but 
> you can access them as the "value" property too, which is a noun that 
> will call the function as necessary when an action is needed. (As a 
> bonus, this makes "writeln = 2" illegal.)

Cool. If I only defined getEmpty, to I get to still use empty?

> 2. the inconsistency for functions and properties returning something 
> such as a delegate or a struct or class with an opCall member, where you 
> absolutely need to write the function with a parenthesis to actually 
> call the returned value. You can either call the function 
> "getMyDelegate()(delegate_arg)" or use the property 
> "myDelegate(delegate_arg)" just as you can with a field.

Very nice solution indeed.

> This syntax doesn't solve the operator overloading issue. It isn't meant 
> to do that either: properties should stay simple.

Which issue are you referring to? +=?

> The two small problems it pose are:
> 
> 1. There's an ambiguity when another symbol is named after the property 
> name that would call the get/set function. I suggest that this other 
> symbol simply hide the property.

I wonder what should happen when this happens across scopes, e.g. in 
base and derived classes.

> 2. You need an uppercase algorithm in the compiler to be able to 
> translate "property" to "setProperty" and "getProperty" and do the 
> proper lookup. This works well for ASCII, but can it go messy with Unicode?

Good question.

> To avoid converting to unicode upercase, we could use "get_thing" and 
> "set_thing" (nicer than opGet/opSet), although that doesn't really fit 
> with the coding standards of D.

Also, again, if you want to define "_thing" you'd have to write 
"get__thing" and "set__thing". Maybe we could lift the restriction about 
two underscores and only keep it for two leading underscores.


Andrei