property / getProperty() / setProperty()

[Michel Fortin]

On 2009-08-01 11:31:17 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

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

Well, yes and no. You could map both the property "thing" and "Thing" 
to "setThing"/"getThing", thus making the first character of a property 
case-insensitive. That's a little awkward, though. But that's exactly 
what key-value coding does for getting and setting value in Objective-C 
[1].

[1]: 
http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/Concepts/Compliant.html


and 

> the latter can't define a property starting with an underscore. 
> (Symbols can't contain two underscores.) Ideas?

This has been shown to not be the case by Jarret. So set_thing and 
get_thing can work indeed.

I don't like that underscore much though: it looks like a special 
syntax for properties that goes against the language style guidelines. 
Sure you can change the style guidelines to adopt them, but this syntax 
will still look out of place.


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

Exactly. You define "bool getEmpty()" and the compiler rewrites any 
call to a property "empty" as "getEmpty()".


>> 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? +=?

This, and any other operator of this kind (++, --, *=, etc.).


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

And I wonder more what happens with the various protection attributes. :-)


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

For instance, isn't ß a lowercase-only letter in German that gets 
traslated to SS in uppercase? (I'm not very familiar with German.)


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