On Thu, 24 Jan 2013 14:26:50 -0800, Robert <[email protected]> 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 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
@Robert, C#'s auto-properties actually do something very close to that.
Consider:
property int Count { get; set; }
A read-write integer property with an automatically implemented getter and
setter functions in IL.
property int Count { get; }
A read-only integer property with an automatically implemented getter
function.
property int Count { set; }
A write-only integer property with an automatically implemented setter
function. This is rarely used, but I have seen it.
C# then creates an unseen field _CountBacking that is only the IL, not in
the user code. The getter/setter then work against this field.
This capability was first introduced in C# 3.0 in 2005. The majority of
properties are implemented this way in C# care nowadays.
The one problem with your example is that you haven't defined a way to
make the property read-only/write-only like in C#.
--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
