2013/2/6 Jonathan M Davis <jmdavisProg@gmx.com>

Being able to initially use a public variable and then swap it out later for
property functions when refactoring is generally the reason that I've heard
for why properties exist in the first place in C#. It's what a number of people
around here seem to think is a core feature of properties, and a core feature
isn't feature creep. And if @property on a variable makes it so that it lowers
to getter and setter property functions (rather than leaving it as a public
variable with certain restrictions on it), then we don't even have to worry
about which features of a variable property functions do and don't emulate and
whatever feature creep might appear there. The "variable" would immediately
match due to the fact that you'd actually end up with property functions. You
just wouldn't have had to do all the boilerplate for it.

I fully agree with Andrei.

I can see that swapping public data field to property function call is not rare, but in almost case, such refactoring also intends to add encapsulation.

struct S {

// Before swapping

int _data;

// After swapping

private int _data;

@property int data() { return _data; }

@property void data(int n) { enforce(n > 0); _data = n; }

}

S s;

int n = s.data;

s.data = 1;

//int* pdata = &s.data;

// changed to disallowed ... it is mostly intended.

> Unprotected, unchecked member variables that can be get and set without
> any hooks into the enclosing structure are rare. That's not the case we
> should help and cater for. When that's the case, the entire object is
> legitimately a "bag of values" that has only public data.

Really? In my experience they're quite common. It's usually the case that not
all of the variables on a type have pass-through getters and setters, but it's
quite common to have at least a few which do. It's been brought up a number of
times in the past that it would be nice to have @property on variables be used
to avoid the boilerplate code in those cases. I suppose that we could use a
mixin to solve that problem, but then you wouldn't get any documentation on
it, since you can't document anything that's mixed in.

Wrapping a field data with property function but also allow accessing to it directly through pointer is quite rare.

struct S {

// After swapping

private int _data;

@property ref int data() { return _data; } // ref return

@property void data(int n) { enforce(n > 0); _data = n; }

}

S s;

int n = s.data; // call getter

s.data = 1; // call setter, enforce n > 0

int* pdata = &s.data; // But, if this is allowed,

*pdata = -1; // this is accidentally allowed... Is this really intended?

To me, it is just a encapsulation breaking.

I'm not sure that it is what you would really expect.

Kenji Hara