On 2013-01-24 23:26, Robert wrote:
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 really like this. Although this is not really what the rest of the
thread is about can could perhaps be introduced separately.
What I like about this is that I get a virtual property and doesn't have
to write the boiler plate code by hand.
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?
Scala solves the first one by always implementing public instance
variables as virtual functions.
--
/Jacob Carlborg
