Is defining get/set methods for every field overkill?

[Ali Çehreli]

On 11/18/22 19:35, [] () {} () wrote:

 > I like to see an example, of a 'class type' with 'public' member
 > variables, somehow magically converted into both getter and setter using
 > UFCS, without breaking client code.

UFCS was mentioned before in the same context but I think what is meant 
was the D feature where functions can be called without parenthesis.

Let's say, we have a pure data type:

struct Point {
     int x;
     int y;
}

void clientCode() {
     auto p = Point();
     p.y = p.x + 42;
}

void main() {
     clientCode();
}

<aside>It took me 20 years to first think that public access to members 
was extremely wrong to then realize that there may not be any problem 
with it at all. As you said, "business logic" (I prefer "invariants") 
warrants limiting access to members. Without anything to protect, it is 
just extra work for no reason at all. (I fully agree with the posted video.)
</aside>

Ok, let's say that the business requirements changed and we wanted to 
perform some business logic. Thanks to D's pragmatism, clientCode() does 
not change at all:

struct Point {
     int x_;    // Rename
     int y_;    // Rename

     auto x() {    // Getter
         return x_ + y_;
     }

     auto y(int value) {  // Setter
         x_ = value * 2;
         y_ = value / 2;
     }
}

void clientCode() {
     auto p = Point();
     p.y = p.x + 42;
}

void main() {
     clientCode();
}

There: clientCode() is not broken.

Ali