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

[Adam Wilson]

On Thu, 24 Jan 2013 14:26:50 -0800, Robert <jfanatiker at gmx.at> 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/