DIP23 Counter Proposal

[Dan]

On Thursday, 7 February 2013 at 20:26:10 UTC, Jonathan M Davis 
wrote:
> It works as long as you can limit the variable in some way. But 
> I believe that
> the main purpose in using public variables rather than actual 
> property
> functions when all they would do is get or set the variable is 
> to avoid lots
> of boilerplate code. It's incredibly common to get stuff like
>
> struct S
> {
>  int i() @safe const pure nothrow
>  { return _i; }
>
>  int i(int value) @safe pure nothrow
>  { return _i = value; }
>
>  private int _i;
> }
>
> That's a lot of extra code whose only benefit is encapsulation. 
> So, it would be
> great if you could just do
>
> struct S
> {
>  int i;
> }
>
> And with the ability to replace the variable with a property 
> function later if
> it ever needs to do more than just get or set makes it so that 
> encapsulation
> isn't a problem - except for the fact that there are certain 
> operations that
> you can do on a variable that you can't do on a property 
> function (e.g. taking
> its address or passing it by ref). Simply making it so that 
> doing
>
> struct S
> {
>  @property int i;
> }
>
> lowered into something like the first example would allow you 
> to avoid all of
> that boilerplate code and still have full encapsulation.

If it lowered into something like the first example would there 
really be any encapsulation? Wouldn't that be exactly the same as 
public int i?

If this is the goal - to get rid of the boilerplate of accessors, 
it makes sense but a new feature is not necessary.

If you want read/write access to a member but the benefit of 
being able to intercept access in the future start with struct S 
{ int i; }. When the need arises to change the behavior, switch 
to:

struct S {
   int i() @safe const pure nothrow
   {
     // SPECIAL SAUCE
     return _i;
   }

   int i(int value) @safe pure nothrow
   {
     // SPECIAL SAUCE
     return _i = value;
   }

   private int _i;
}

If you don't have any SPECIAL SAUCE then you don't need to switch.

If you want more encapsulation and specifically don't want to 
provide write access, just read access then a mixin can do the 
trick of providing read access to s.i. In the future you can 
change the read accessor and provide one with SPECIAL SAUCE.

struct S {
    mixin ReadOnly!_i;
    private int _i;
}

>
> It's definitely true that you can never make a property 
> function completely
> emulate a variable, but all of the boilerplate required for 
> simple getters and
> setters is kind of ridiculous. I believe that avoiding that is 
> the primary
> reason that people want to be able to swap between variables 
> and property
> functions, and with a small addition to the language, we can 
> obviate that
> boilerplate.
>

No addition needed.

Thanks
Dan