DIP23 draft: Fixing properties redux

Jacob Carlborg doob at me.com
Tue Feb 5 00:31:22 PST 2013


On 2013-02-05 07:13, Jonathan M Davis wrote:

> One of the main purposes generally given for having properties is so that you
> can make them public variables when you don't need them to do anything but get
> and set the member variable, but you can still make it a function later when
> you need to add other stuff to it (such as checking the value that it's being
> set to). One of the primary reasons for making a property function act like a
> variable is precisely so that you can switch between variables and functions
> when refactoring without breaking code.
>
> Also, being able to mark variables as @property would save us a lot of
> boilerplate. Instead, it's incredibly common to do stuff like
>
> struct S
> {
>      @property int prop() @safe const pure nothrow
>      { return _prop; }
>
>      @property int prop(int value) @safe pure
>      { return _prop =  value; }
>
>      private int _prop;
> }
>
> That's a lot of extra code just to buy some encapsulation. If we could do
>
> struct S
> {
>      @property int prop;
> }
>
> we could really reduce the amount of boilerplate code surrounding member
> variables. Even if putting @property on a variable simply lowered to the
> property functions rather than it still be a variable, it would be a big help.
> But without either that or marking variables with @property so that you can't
> do anything to them that you can't do to a property function, we lose the
> ability to make a property a variable when the getters and setters are
> unnecessary, and that means that we're stuck with a lot of extra boilerplate.

I fully agree. But they do need to be lowered to methods, see:

http://forum.dlang.org/thread/kel6c8$1h5d$1@digitalmars.com?page=17#post-keqfol:242un9:241:40digitalmars.com

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list