<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2013/2/6 Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com" target="_blank">jmdavisProg@gmx.com</a>></span><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

Being able to initially use a public variable and then swap it out later for<br>
property functions when refactoring is generally the reason that I've heard<br>
for why properties exist in the first place in C#. It's what a number of people<br>
around here seem to think is a core feature of properties, and a core feature<br>
isn't feature creep. And if @property on a variable makes it so that it lowers<br>
to getter and setter property functions (rather than leaving it as a public<br>
variable with certain restrictions on it), then we don't even have to worry<br>
about which features of a variable property functions do and don't emulate and<br>
whatever feature creep might appear there. The "variable" would immediately<br>
match due to the fact that you'd actually end up with property functions. You<br>
just wouldn't have had to do all the boilerplate for it.<br></blockquote><div><br></div><div>I fully agree with Andrei.</div><div>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.</div>
<div><br></div><div>struct S {<br></div><div>    // Before swapping</div><div>    int _data;</div><br class=""><div>    // After swapping</div><div>    private int _data;</div><div>    @property int data() { return _data; }</div>
<div>    @property void data(int n) { enforce(n > 0); _data = n; }</div><div>}</div><div>S s;</div><div>int n = s.data;</div><div><div>s.data = 1;</div>//int* pdata = &s.data;</div><div>// changed to disallowed ... it is mostly intended.</div>
<div><br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
> Unprotected, unchecked member variables that can be get and set without<br>
> any hooks into the enclosing structure are rare. That's not the case we<br>
> should help and cater for. When that's the case, the entire object is<br>
> legitimately a "bag of values" that has only public data.<br>
<br>
Really? In my experience they're quite common. It's usually the case that not<br>
all of the variables on a type have pass-through getters and setters, but it's<br>
quite common to have at least a few which do. It's been brought up a number of<br>
times in the past that it would be nice to have @property on variables be used<br>
to avoid the boilerplate code in those cases. I suppose that we could use a<br>
mixin to solve that problem, but then you wouldn't get any documentation on<br>
it, since you can't document anything that's mixed in.</blockquote><div><br></div><div>Wrapping a field data with property function but also allow accessing to it directly through pointer is quite rare.</div><div>
<br></div><div><div>struct S {<br></div><div>    // After swapping<br></div><div>    private int _data;</div><div>    @property ref int data() { return _data; }  // ref return</div><div>    @property void data(int n) { enforce(n > 0); _data = n; }</div>
<div>}</div><div>S s;</div><div>int n = s.data;  // call getter</div><div>s.data = 1;  // call setter, enforce n > 0</div><div>int* pdata = &s.data;  // But, if this is allowed,</div><div>*pdata = -1;  // this is accidentally allowed... Is this really intended?</div>
<br class=""></div><div>To me, it is just a encapsulation breaking.</div><div>I'm not sure that it is what you would really expect.</div><div><br></div><div>Kenji Hara</div></div></div></div>