DIP23 draft: Fixing properties redux

[Jonathan M Davis]

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