DIP23 draft: Fixing properties redux

[kenji hara]

2013/2/6 Jonathan M Davis <jmdavisProg at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130206/9b14270e/attachment-0001.html>