www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - When should I make property functions?

reply Trent Caprico <email example.com> writes:
In Java, it is considered best to always make all member 
variables private, and make getters/setters for the 'public' 
members.

In D, should I create  property functions for all 'public' fields 
when I first define the class, or is it best to wait until a 
property function is actually needed?
Nov 19 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, November 19, 2018 1:11:11 PM MST Trent Caprico via Digitalmars-d 
wrote:

 In Java, it is considered best to always make all member
 variables private, and make getters/setters for the 'public'
 members.

 In D, should I create  property functions for all 'public' fields
 when I first define the class, or is it best to wait until a
 property function is actually needed?


In general, you should prefer to keep the fields private. While property
functions do simulate variables, they don't really follow the same semantics
(e.g. taking the address doesn't do the same thing, and you can pass a
variable by ref, but you can't pass a property function by ref). So, if you
change a public member variable to a property function later, you risk
running into problems - this is especially true if you're providing a
library for other people to use as opposed to simply writing a type for use
in your own application where you control all of your code. Another
consideration is that invariants are called before and after public
functions are called (assuming that you don't compile with -release), so if
your type has an invariant, it will be called before and after a call to a
public property function, whereas if you have a public member variable, the
invariant isn't checked at all.

These considerations are of course lessened if we're talking about a type
that is just inside your application where you're in complete control of all
code that uses it, so you if you later change the type, you can change all
code using it (whereas with libraries that you make available, you have to
be far more careful), but the basic reasons for why you would make member
variables private in languages such as Java still apply. Ultimately,
property functions in D are pretty much just a nice syntactic improvement
over getters and setters. They don't really change the fundamental issues
surrounding public member variables.

- Jonathan M Davis
Nov 19 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 19 November 2018 at 20:36:42 UTC, Jonathan M Davis 
wrote:

 [...]


Expect for the fact that they can't do binary assignment.
https://github.com/dlang/DIPs/pull/97
Nov 19 2018
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, November 19, 2018 1:52:20 PM MST 12345swordy via Digitalmars-d 
wrote:

 On Monday, 19 November 2018 at 20:36:42 UTC, Jonathan M Davis

 wrote:

 [...]


 Expect for the fact that they can't do binary assignment.
 https://github.com/dlang/DIPs/pull/97


Well, that's kind of my point. Property functions do not act the same way as
member variables, and ultimately they can't, because they're fundamentally
different. There may or may not be further language enhancements to make
them more syntactically similar, but ultimately, a property function is
_not_ a member variable, and you will never be able to just swap out a
public member variable for a property function and expect all code using it
to just continue to work. So, in general, you should not make your member
variables public with the idea the you might then later turn them into
property functions when refactoring if it turns out that you want them to be
more than simple getters ands setters. This is especially true if you're
writing code that you're providing to other people rather than writing code
that you're in complete control of and therefore can fully update if/when it
breaks if you later decide to change a member variable into a property
function.

- Jonathan M Davis
Nov 19 2018
prev sibling parent Neia Neutuladh <neia ikeran.org> writes:
On Mon, 19 Nov 2018 20:52:20 +0000, 12345swordy wrote:

 On Monday, 19 November 2018 at 20:36:42 UTC, Jonathan M Davis wrote:

 [...]


 
 Expect for the fact that they can't do binary assignment.
 https://github.com/dlang/DIPs/pull/97


And you can't take the address of a getter/setter pair.
Nov 19 2018
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
On Monday, 19 November 2018 at 20:11:11 UTC, Trent Caprico wrote:

 In Java, it is considered best to always make all member 
 variables private, and make getters/setters for the 'public' 
 members.

 In D, should I create  property functions for all 'public' 
 fields when I first define the class, or is it best to wait 
 until a property function is actually needed?


I consider getters a code smell and setters a code stink. 
Sometimes they're needed, but one should never be happy about 
using them.

Tell, don't ask: https://martinfowler.com/bliki/TellDontAsk.html

The more the class/struct clients know about the internals, the 
greater the coupling and that's never a good thing.
Nov 20 2018