Fixing D's Properties
BCS
ao at pathlink.com
Fri Aug 17 12:22:57 PDT 2007
Reply to Chad,
> -------------------------------------(1)
>
> First, the very common ambiguity:
>
> Does
> foo.bar++;
> become
> foo.bar( foo.bar + 1 );
> or
> foo.bar() + 1;
> ??
> This is why we can't write things like this:
>
> ubyte[] array = new ubyte[50];
> //...
> array.length++;
> //...
> array.length += 10;
> // Note how builtin types use properties heavily.
> Which means a large set of our beloved shortcut operators are
> completely broken on properties.
>
This is not an syntax issue with how proposes are defined, but the semantics
of there use.
It can be fixed with minor changes.
> -------------------------------------(2)
[...]
this is the same as #1 (or am i missing somthing)
> -------------------------------------(3)
>
> Third, there is a problem with value types and properties. Consider
> the following code:
>
short version:
struct S {int i; void I(int j){i=j;} }
struct P {S s void GetS() { return s;} }
P p;
p.GetS.I = 5; // assignes 5 to temp, not member of p
This is a reference semantics issue. The same isses happens to general functions.
> -------------------------------------(4)
>
> Fourth, delegates get the shaft.
Short version:
void delegate() getDG();
getDG(); // calls getDG giving a delgate
getDG(); // calls getDG, does not call returned delegate
good point.
>
> -------------------------------------(5)
>
> Fifth, delegates aren't over with yet. This isn't nearly as bad as
> the
> other 4, but it should hit eventually.
> Properties can be converted into delegates.
[...]
> The problem is, what if, for whatever reason, the author of similar
> code
> someday wanted to demote those properties back to fields?
> In that case, the user code that relies on the delegate will fail.
[...]
> Realizing that this behavior of properties can be beneficial, it makes
> sense to show that similar code can be written without properties and
> without much added difficulty.
[...]
> struct Point
> {
> int x,y;
> }
> void main()
> {
> Point p;
> int getX() { return p.x; }
> int delegate() readX = &getX;
> p.x = 2;
> printf( "%d", readX() ); // prints 2
> }
ouch! that sounds worse than the problem you point out.
> ========================================
> How to fix it
> ========================================
[...]
> *lvalue: If foo is an lvalue, than foo = 5; should set foo's value to
> 5, instead of evaluating to 5; and doing nothing. Implicit write
> properties fake this to some extent, but do not hold in the general
> case. Example (3) above and the foo++; and foo+=10; issues are
> examples
> where lvalueness is needed.
I would disagree. I would clam that the issue is that implicit properties
can be used a lvalues or rvalues, but not both.
[......]
The basis of your thoughts seem to come from the idea that hiding the fact
that properties are functions would be a good thing. I would assert that
this is highly debatable. I will concede that the current semantics of properties
being not quite interchangeable with fields is sub optimal. However fixing
this by creating a new construct that, in the end, is identical to a function
but with a number of things forbidden seems somehow wrong.
As I see it the issues you bring up amount to:
1> no L/R-value usage (++, +=, etc, use as an inout or out arg)
2> they can lead to hard to find reference semantics issues
3> syntax problems with properties retuning delegates
4> not interchangeable with fields
#1 can be fixed without explicit properties
#2 is not at all a problem in my book
#3 This is a tiny corner case
#4 this is a good point, however, as stated above, I don't like the proposed
solution. Also, the proposed solution doesn't fix the issue because taking
the address of a field is allowed, even with explicit properties, this wouldn't
work
IMHO there are a few minor issues with proposes that could uses a little
work. However I don't see much to be gained by you proposal for explicit
properties.
> This post is a bit lengthy. So assuming you've read even part of it,
> thank you for your time.
> - Chad
It's good to see people thinking about this stuff. I may not see your ideas
to be the "right" way but, then again, I want different things out of D than
many people do.
More information about the Digitalmars-d
mailing list