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

On 11/18/22 20:13, [] () {} () wrote:

> after 10 years of doing all that, you may well come to the conclusion
> that public member variables are not such a great idea afterall ;-)

It depends. Majority of my structs are pure data. When there is no invariant to protect, then there is no reason to write any accessor.

If 10 years is mentioned to prove a point, I currently have 33 years of professional programming experience (37 including pure hobby years), so I must be right. ;)

Ali

On 11/19/22 01:05, [] () {} () wrote:

> All this because some programmer wanted to save a few key strokes, or
> did not anticipate change, or did not anticipate the need to ensure data
> is valid before assigning it, or returning it.
>
> So no. It's not overkill. It's called software engineering.

I disagree. Engineering is about applying different solutions to different problems. Blindly following guidelines whether it is fit for purpose would be dogmatic, not pragmatic.

Ali

On 11/19/22 01:43, [] () {} () wrote:

> do it your way for the next 10 years, and
> I bet you will eventually come to a different point of view ;-)

Hm... I am responding without reading the rest of the thread so I don't know whether you've mentioned the 10 years more but here it goes: I hope 11 years will be sufficient to stop following guidelines blindly. Especially this specific one where a posted video has shown how wasteful it can be.

> if you're just a hobyist programmer, then you're really free to do as
> you please.

I am a professional programmer and I do not write public accessors blindly. As stated before, they are written only when there is an invariant to protect.

> but if you are a software engineer employed by a company, within a team
> of other software engineers, then you have to a have framework that you
> *all* work against.

Agreed.

> anyone who says otherwise, doesn't know what they're talking about.

Agreed.

> In my team, 'classes' do not have public member variables. not ever.

I am not working there! :) And what about structs? ;)

> another team is free to do as it pleases of course ;-)

Thanks. :)

> but members of that team will have a hard time getting into my team.

Mutual feelings there...

Ali

On Saturday, 19 November 2022 at 19:59:20 UTC, Ali Çehreli wrote:
> ..
> ...
> Ali

The 10 years was mentioned, because it was what I learnt over that period (well, long before that actually). It wasn't mentioned to demonstrate that I have some superior knowledge. Object data needs to be protected. It often needs its 'invariants' altered.

There are far more reasons for inserting getters/setters and design stage, than leaving them out at design stage, in order to save some keystrokes, or code bloat.

How often do you design your class? How often to users use your class, and ask for changes? Better to anticipate change - the cost of that is much smaller  at design time.

If you learnt something different over your 30+ years, good for you, and your team, and your customers.

But in my experience, public member variables rarely make sense in a 'class' type, and I'd put protected in the same principle.

This is not a hard and fast rule. But it makes sense in most cases.

Perhaps you can direct me to a software engineering *team* that builds *class* library's for a living, and that also use public member variables in their classes. Perhaps they can teach me something I do not know. I'm happy to learn more.

Your post was mainly about struct types?? This thread is about the relevance of getters/setters in a 'class' type.

btw. If you can get away with using public member variables, you likely don't need a class type.

On Saturday, 19 November 2022 at 19:59:20 UTC, Ali Çehreli wrote:
> On 11/19/22 01:43, [] () {} () wrote:
>
> > do it your way for the next 10 years, and
> > I bet you will eventually come to a different point of view
> ;-)
>
> Hm... I am responding without reading the rest of the thread so I don't know whether you've mentioned the 10 years more but here it goes: I hope 11 years will be sufficient to stop following guidelines blindly. Especially this specific one where a posted video has shown how wasteful it can be.
>

You mention your 30+ years of programming, but at the same time, point out how 'correct' that one-sided rant is in that video.

I'm confused ;-)

On Saturday, 19 November 2022 at 19:54:59 UTC, Ali Çehreli wrote:
> On 11/19/22 01:05, [] () {} () wrote:
>
> > All this because some programmer wanted to save a few key
> strokes, or
> > did not anticipate change, or did not anticipate the need to
> ensure data
> > is valid before assigning it, or returning it.
> >
> > So no. It's not overkill. It's called software engineering.
>
> I disagree. Engineering is about applying different solutions to different problems. Blindly following guidelines whether it is fit for purpose would be dogmatic, not pragmatic.
>
> Ali

Neither I, nor anyone in my team blindly follows anything, or anyone ;-)

What goes on inside an object, is the responsibilty of that object.

That's a guideline (i.e. encapsulation) that we accept as being an important principle in software *engineering*, for us, and for all of the reasons I've mentioned, and so we implement and follow it.

Not having that encapsulation would (and has) create major problems for us, and our customers.

Again, if you and/or your team have discovered something different (i.e. encapsulation is not that important afterall), then that's great, for you. But it wouldn't be great for us, or our customers, that much I do know.