Re: @property get/set or public varaible?

2016-12-05 Thread ArturG via Digitalmars-d-learn
On Sunday, 4 December 2016 at 20:44:05 UTC, Jonathan M Davis 
wrote:
On Sunday, December 04, 2016 15:30:22 vladdeSV via 
Digitalmars-d-learn wrote:

Hello!

I have a question not directly related to D as it is with 
coding standards.


My issue at hand is if I have one variable for a class, which I
want to be directly accessible for anything else, should it be
  1. public, or
  2. private, with @property get/setters?

 From what I have been told is that variables should be 
private.
But if I do not want to make any checks whatsoever when 
setting a

variable, I see no benefit to the private approach.

Are there any other reasons to use get/setters?





This might not be usefull for ure current usecase but if you want 
a property to behave like a field, it has to be a field.
So a boxed type might be better depending how much you want to 
manage.

Here are some property like examples:

   struct Prop(T)
   {
  private T value;

  alias opCall this;
  ref T opCall() { return value; }
  ref T opCall(T val) { return value = val; }
  string toString() { import std.conv: to; return 
value.to!string; }

   }

   struct ReadOnly(T)
   {
  private T value;

  alias opCall this;
  T opCall() { return value; } // return a copy
  string toString() { import std.conv: to; return 
value.to!string; }

   }

   struct WriteOnly(T)
   {
  private T value;

  void opAssign(T val) { value = val; }
  string toString() { return typeof(this).stringof; }
   }

// alternative write only so you can chain opCall 
writeOnly(33)(56)(66);

struct AltWriteOnly(T)
   {
  private T value;

  ref typeof(this) opCall(T val) { value = val; return this; }
  string toString() { return typeof(this).stringof; }
   }

   struct FunProp(T) if(isSomeFunction!T)
   {
  private T value;

  alias value this;
  void opAssign(T val) { value = val; }
  string toString() { return T.stringof; }
   }


   class Test
   {
   Prop!int someVal;
   ReadOnly!string name;
   WriteOnly!int someOtherVal;
   FunProp!(void delegate(int)) funProp;

   this()
   {
   name.value = "Test";
   }
   }

   void main()
   {
   auto test = new Test;
   test.someVal = 66;
   test.someVal++;
   test.someOtherVal = 100;
   test.funProp = (int i) => i + test.someVal;
   test.someVal.writeln;
   test.name.writeln;
   test.funProp(33).writeln;
   test.funProp.writeln;
   test.someOtherVal.writeln;
   }

haven't done extencive tests with them but they can be used as 
builing blocks, you can add other operator overloads to manage 
other access to the value.

you can build better properties without @property :/


Re: @property get/set or public varaible?

2016-12-04 Thread Jonathan M Davis via Digitalmars-d-learn
On Sunday, December 04, 2016 15:30:22 vladdeSV via Digitalmars-d-learn 
wrote:
> Hello!
>
> I have a question not directly related to D as it is with coding
> standards.
>
> My issue at hand is if I have one variable for a class, which I
> want to be directly accessible for anything else, should it be
>   1. public, or
>   2. private, with @property get/setters?
>
>  From what I have been told is that variables should be private.
> But if I do not want to make any checks whatsoever when setting a
> variable, I see no benefit to the private approach.
>
> Are there any other reasons to use get/setters?

The big reason to use getters and setters over public variables is that
converting public variables to property functions is _not_ seemless.
Property functions act like variables for some basic operations like
assignment, but you try and do much more than that, and they start behaving
drastically differently. For instance, what happens if someone takes the
address of a property? Or passes it by reference? As long as that property
is a member variable, it works like a variable, but if it's changed to a
property function, then those operations either have different types and
don't compile with existing code, or the operations don't work at all. Even
basic operations such as ++ don't work with property functions.

I'm sure that there are folks in the D community who favor using public
variables rather than property functions if they're not going to do anything
beyond getting or setting, but you're at serious risk of code breakage if
you do - especially if you're doing it in an API that you're distributing to
other people. For your own personal stuff or stuff that is internal to
whatever project you're doing where you can change all of the code that uses
the property, then it can work to use a public variable and then change the
code later if necessary if and when it becomes a property function. And
since most public variables don't get turned into property functions later,
you probabably will only have to deal with code breakage rarely, and it will
be easy for you to fix the few places where the property was used in a way
that works for a public variable but not for a property function. But if
you're distributing a library with a property that's a public variable, you
can't change all of the code using that property, and changing it to a
property function could easily break other people's code.

So, do what you want for internal stuff, but don't use public member
variables in libraries that you're distributing unless it's certain that
they will never be anything but public variables.

- Jonathan M Davis



Re: @property get/set or public varaible?

2016-12-04 Thread ketmar via Digitalmars-d-learn

On Sunday, 4 December 2016 at 15:30:22 UTC, vladdeSV wrote:

Are there any other reasons to use get/setters?


basically, no. as you can omit parentheses in D, converting to 
getter/setter later should be seamless.


the only reason to have getter/setter in your case is a situation 
where you may want to override 'em in child class. so if you are 
using class hierarchy, take some time to think if you will ever 
need such overrides.


Re: @property get/set or public varaible?

2016-12-04 Thread angel via Digitalmars-d-learn

On Sunday, 4 December 2016 at 15:30:22 UTC, vladdeSV wrote:

Hello!

I have a question not directly related to D as it is with 
coding standards.


My issue at hand is if I have one variable for a class, which I 
want to be directly accessible for anything else, should it be

 1. public, or
 2. private, with @property get/setters?

From what I have been told is that variables should be private. 
But if I do not want to make any checks whatsoever when setting 
a variable, I see no benefit to the private approach.


Are there any other reasons to use get/setters?


Make the member variable public, if it serves your purpose.
If (and when) you feel like taking some control over setting and 
getting its value, you will upgrade it to @property 
setter/getter, making the actual member variable private.
For most reasonable use cases the upgrade should pass with no 
problems.

...
If you envision such an upgrade possibility, try to keep away 
from taking your member variable address, and other not 
method-friendly operations, that might hold the upgrade back.