On Friday, 18 November 2022 at 20:18:41 UTC, matheus wrote:
> 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...".

ok. But then you've made the member variable a part of the interface to the client, and if you even need to constrain the value being assigned to the member, you will have to break that interface.

In production-level code, it is rare you would allow unconstrained access to a member variable. Not unheard of, just rare. And in any case, a simple accessor allows you to do so, should you're business rules ever change.

You should plan for change, in production-level code. That's the 'point' missing from that rant in that video.

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

It likely already does something, in that- >'it allows for change to occur without having to break the clients interface'.

That too is the 'point' missing from that rant.

>
> It likely already does something, in that- >'it allows for change to occur without having to break the clients interface'.
>
> That too is the 'point' missing from that rant.

With all due respect, I think your point is mostly invalid due to the point that Dukc made.

On Saturday, 19 November 2022 at 03:08:05 UTC, thebluepandabear wrote:
>>
>> It likely already does something, in that- >'it allows for change to occur without having to break the clients interface'.
>>
>> That too is the 'point' missing from that rant.
>
> With all due respect, I think your point is mostly invalid due to the point that Dukc made.

keep programming/maintaining and enhancing production-level code for the next 10 years.

then you too will know the correct answer to your question :-)

On Saturday, 19 November 2022 at 03:14:18 UTC, []() {}() wrote:
> On Saturday, 19 November 2022 at 03:08:05 UTC, thebluepandabear wrote:
>>>
>>> It likely already does something, in that- >'it allows for change to occur without having to break the clients interface'.
>>>
>>> That too is the 'point' missing from that rant.
>>
>> With all due respect, I think your point is mostly invalid due to the point that Dukc made.
>
> keep programming/maintaining and enhancing production-level code for the next 10 years.
>
> then you too will know the correct answer to your question :-)

I think because of uniform function call syntax, getters/setters are not needed even for production level code, in D of course. In Java, you do need them so your point holds true in that scenario, but in D I don't really see the point after giving it some thought, I would say they are code bloat.

On Saturday, 19 November 2022 at 03:24:41 UTC, thebluepandabear wrote:
>
> I think because of uniform function call syntax, getters/setters are not needed even for production level code, in D of course. In Java, you do need them so your point holds true in that scenario, but in D I don't really see the point after giving it some thought, I would say they are code bloat.

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.