property / getProperty() / setProperty()

[Michel Fortin]

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.

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 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

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.

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.)

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.

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

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.

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?

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.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/