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