On Tuesday, 29 January 2013 at 17:10:00 UTC, Steven Schveighoffer
wrote:
@property has gotten a lot of flak lately, and I think the
unenthusiastic implementation of it really hasn't helped.
BUT... there are a few problems with the original non-@property
implementation that are fixed by having additional syntax
(well, if it was properly implemented):
1. Treating any old function as a setter. This is the writeln
= "hi"; mess
2. Forcing you to use 2 sets of parentheses when returning a
callable type.
However, we have seen the addition of two problems with
@property. First is when UFCS was introduced.
@property int iprop(int val) {...}
can be called as:
52.iprop;
or
iprop = 52;
Second problem is, when ref returns are used on properties:
@property ref int iprop();
auto x = &iprop;
Should x be the delegate for iprop, or call iprop and get the
address of the return value?
ASIDE from the disdain that many developers have towards
@property, I think above anything else, that the first problem
@property fixed above is essential to the freedom of naming
functions for API designers. The second problem of getting
delegates via properties is fixed, so it would be a step
backwards if we just removed @property.
So in light of all that, I propose a compromise:
1. Deprecate @property.
2. When the compiler encounters a field setting like this:
x.y = ...;
If a y field exists on the aggregate represented by x, then
that is the assumed member being referenced, and compilation
continues normally.
If there is no y field, then then the compiler ALSO tries:
x.setY(...);
no, just no.
It is important to note that:
x.y(...);
does not compile, y is not just another function. To call in
function form, you must call:
x.setY(...);
That takes care of setters, AND takes care of the new problems
with @property.
3. Parentheses remain optional on functions, allowing the
creation of getters as before @property.
However, this does not fix the delegate problem. To fix that
problem, we can use the complementary getY to allow specifying
a getter that does not absorb parentheses.
One problem I will note with this scheme, some Unicode symbols
that may be valid D symbol starters may NOT have an upper/lower
case, making it impossible to use those as properties. But I
admit having an English bias so I don't see this as a large
problem. Besides, "set" is already English.
"natural language inspiration" ... hmm .. where have I seen this?
oh right, let's make a DOBOL.
Note, I've been doing a lot of Objective C lately, and I kind
of like the property scheme there (this is quite similar).
Sound crazy? Ridiculous? Impossible? Insulting?
What do you think?
-Steve
more like all four combined.
