On Tuesday, February 05, 2013 08:31:46 Andrei Alexandrescu wrote: > On 2/5/13 3:39 AM, Dmitry Olshansky wrote: > > On 02/05/2013 02:28 AM, Andrei Alexandrescu wrote:> On 2/4/13 2:04 PM, > > > > Jonathan M Davis wrote: > > >> We could save a lot of boilerplate code if we can simply make it > > >> variables and > > >> property functions guaranteed to be swappable without breaking code. > > > > > > I think this is quite powerful. The way we can do this is by making > > > properties emulate a subset of actual variables. > > > > This is the primary real-world proble to solve. > > The problem with this approach is feature creep - there will always be > yet another possible case in which a feature helps some case. We need to > put a halt on that.
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. > 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. - Jonathan M Davis
