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

[Jacob Carlborg]

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