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?

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

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

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

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.

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.