I wouldn't bother.

They are const, they can't change.

Nothing to protect, nothing to synchronize.

On 11/16/22 20:39, thebluepandabear wrote:

> I am debating whether or not I should add getter methods to these
> properties.

If you are debating, then the answer is easy: you should not. :)

Less code written means less bugs, more cohesion, easier refactoring, cleaner code, all good stuff...

Even if a design requires e.g. a 'length' method, the default one should be a getter. A setter will come in the future only if 'length = 42' is clearly better than e.g. 'expandTo(42)'.

> in other languages like Java it is a good practice:

I've seen so many tutorials where any user-defined type immediately defines getters and setters. It is never good style to do that. There are good examples of where doing that is clearly wrong. For example, can a Date class really provide a setMonth() setter? It would be so wrong, I don't even know where to begin. (I remember talks by Kevlin Henney where he would use that example.)

The guidelines I follow are simple in the following order:

- Don't write any code until it makes sense :)

- Don't write a getter until it makes sense

- Don't write a setter until it makes sense

Ali

On Thursday, 17 November 2022 at 06:29:56 UTC, Ali Çehreli wrote:
> On 11/16/22 20:39, thebluepandabear wrote:
>
> > I am debating whether or not I should add getter methods to
> these
> > properties.
>
> If you are debating, then the answer is easy: you should not. :)
>
> Less code written means less bugs, more cohesion, easier refactoring, cleaner code, all good stuff...
>
> Even if a design requires e.g. a 'length' method, the default one should be a getter. A setter will come in the future only if 'length = 42' is clearly better than e.g. 'expandTo(42)'.
>
> > in other languages like Java it is a good practice:
>
> I've seen so many tutorials where any user-defined type immediately defines getters and setters. It is never good style to do that. There are good examples of where doing that is clearly wrong. For example, can a Date class really provide a setMonth() setter? It would be so wrong, I don't even know where to begin. (I remember talks by Kevlin Henney where he would use that example.)
>
> The guidelines I follow are simple in the following order:
>
> - Don't write any code until it makes sense :)
>
> - Don't write a getter until it makes sense
>
> - Don't write a setter until it makes sense
>
> Ali
Appreciate your insight.

Btw I think my example is a bit flawed as the fields are const 😂

I would be interested in hearing your thoughts on using 'const'.

Many people claim that all variables should be const by default, but whether or not it is really needed is debatable and oftentimes making everything const could cause readability issues and make the code more complex. There is no real end to how much variables can be const. Oftentimes in popular repos I don't even see const being used.

Some languages like Kotlin and Rust are const by default, but for languages that are not like D I have always wondered how often you should use const.

On Thursday, 17 November 2022 at 04:39:35 UTC, thebluepandabear wrote:
> I am creating a TUI library and I have a class with the following constant fields:
>
> ```
> class Label : Renderable {
>     const string text;
>     const TextAlignment textAlignment;
>     const Color color;
>
>     this(Dimensions dimensions, string text, TextAlignment textAlignment, Color color) {
>         this.dimensions = dimensions;
>         this(text, textAlignment, color);
>     }
>
>     this(string text, TextAlignment textAlignment, Color color) {
>         this.text = text;
>         this.textAlignment = textAlignment;
>         this.color = color;
>     }
>
>     override Cell[] render() const {
>         Cell[] cells;
>
>         for (int x = 0; x < 0 + text.length; ++x) {
>             cells ~= Cell(Coordinates(x, 0), text[x], color);
>         }
>
>         return cells;
>     }
> }
> ```
>
> I am debating whether or not I should add getter methods to these properties. On one hand, it will inflate the codebase by a lot, on the other hand -- in other languages like Java it is a good practice:
>
> ```
> class Label : Renderable {
>     private const string text;
>     private const TextAlignment textAlignment;
>     private const Color color;
>
>     this(Dimensions dimensions, string text, TextAlignment textAlignment, Color color) {
>         this.dimensions = dimensions;
>         this(text, textAlignment, color);
>     }
>
>     this(string text, TextAlignment textAlignment, Color color) {
>         this.text = text;
>         this.textAlignment = textAlignment;
>         this.color = color;
>     }
>
>     string getText() const {
>         return text;
>     }
>
>     TextAlignment getTextAlignment() const {
>         return textAlignment;
>     }
>
>     Color getColor() const {
>         return color;
>     }
>
>     override Cell[] render() const {
>         Cell[] cells;
>
>         for (int x = 0; x < 0 + text.length; ++x) {
>             cells ~= Cell(Coordinates(x, 0), text[x], color);
>         }
>
>         return cells;
>     }
> }
> ```
>
> It's not a lot of code that has been added but if you have a class with say 10 different fields, adding getter methods would definitely increase the code size by a lot, so what are you guys thoughts on this?

The Java code you presented requires getter, since your member variables are private (which is the default in java anyway). In D, public is the default.

First decided whether you really do want them public (because those members now form a part of the interface that you present to the user of that class, which immediately constrains you in terms of changes).

Decide whether they are in fact amenable to direct public access (i.e. do you need to test for null, or have some other rule that you must meet before providing a value back to the caller?

Better to just make them private, and then provide getters. Then if you do need to implement a check for null or whatever, then you can do that with changing the interface.

Controlled access to data (i.e. data protection) should always be the default, unless you are absolutely sure you don't need (and will never need) that controlled access.

> (and will never need) that controlled access.
Thanks. BTW the code is not Java, it is 100% D.

On Thursday, 17 November 2022 at 04:39:35 UTC, thebluepandabear wrote:
> ...
> It's not a lot of code that has been added but if you have a class with say 10 different fields, adding getter methods would definitely increase the code size by a lot, so what are you guys thoughts on this?

Food for thought:

https://yewtu.be/watch?v=_xLgr6Ng4qQ

or

https://www.youtube.com/embed/_xLgr6Ng4qQ

Matheus.

On Thursday, 17 November 2022 at 09:46:57 UTC, matheus wrote:
>
> Food for thought:
>
> https://yewtu.be/watch?v=_xLgr6Ng4qQ
>
> or
>
> https://www.youtube.com/embed/_xLgr6Ng4qQ
>
> Matheus.

'Food for thought'? Sure, if you're feeding that to your dog.

Public fields in 'class' definitions rarely have place in production level code.

How would you enforce the business rules??

Lets say, you have declared a public member variable that is of type int, but must be constrained to be within a particular range of that int?

Well, you cannot enforce a business rule like that using a public member variable. The user of your class can easily corrupt you data, because they can access it directly.

Well, you enforce a business rule, by making it a private member variable and having a public setter that accepts a value and checks whether it meets the business rule, and only if it does, and only if it does, will that value then be assigned to the member variable.

That video link you presented is just dog food. Let your dog think about it. In the meantime, you think about production level code please.

On Friday, 18 November 2022 at 09:42:21 UTC, []() {}() wrote:
> ...

I think you missed the point of that video very badly.

By the way just a few points from that video:

Around: 2:32 -> "Never ever put in an 'accessor' until it actually does something...".

Around: 3:10 -> "If there is an 'accessor' it had better do something in there...".

Matheus.