On 2009-08-01 11:31:17 -0400, Andrei Alexandrescu
<[email protected]> 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
[email protected]
http://michelf.com/
