@property - take it behind the woodshed and shoot it?

Robert jfanatiker at gmx.at
Thu Jan 24 14:26:50 PST 2013


Apart from +=, ++, what breaks compatibility of fields and properties,
is that you can't take the address of a property, but of a field (as
already mentioned). To increase compatibility and in order to avoid
breaking peoples' code, when a field is changed to a property, maybe,
simply offer the possibility to declare fields to be a property too,
with @property. And make it so that the access to such a field behaves
exactly the same as to a property: No address taking, and as long as
properties don't support ++, +=, ... maybe even forbid those.

Example:

@property int a;

would be completely equivalent to:

int a_;

@property int a() {
return a_;
}
@property int a(int new_a) {
 a_=new_a;
 return a_;
}

I think this would suffice to make the property concept really sound and
working in practice.

If, this is considered a good thing, I could create yet another property
DIP.

Another thing I am wondering, will this still be possible:

void myProperty(int a) @property {}

void function(int) dg=&myProperty;

Or in other words, will taking the address of a property method still be
possible? I think it would be quite sensible and useful (for e.g.
std.signals), taking the address of a transient return value does not
make any sense anyway, so no ambiguity here. On the other hand it would
break compatibility with fields again. So if we also want to make sure
the way back (from property methods to field) works, disallowing taking
the address might be the way to go for a finally proper implementation. 

To the C# experts: How does C# solve those two issues?

Best regards,

Robert




More information about the Digitalmars-d mailing list