Is defining get/set methods for every field overkill?

On Saturday, 19 November 2022 at 03:52:41 UTC, thebluepandabear 
wrote:
> On Saturday, 19 November 2022 at 03:39:18 UTC, []() {}() wrote:
>> On Saturday, 19 November 2022 at 03:22:12 UTC, 
>> thebluepandabear wrote:
>>> On Saturday, 19 November 2022 at 03:19:53 UTC, []() {}() 
>>> wrote:
>>>> On Thursday, 17 November 2022 at 09:52:11 UTC, Dukc wrote:
>>>>> ..
>>>>> D has far less need for getters/setters than Java or C++. 
>>>>> The reason is [Uniform Function Call 
>>>>> Syntax](https://ddili.org/ders/d.en/ufcs.html). This means 
>>>>> that a member of a `struct` or `class` can start out as a 
>>>>> normal field and be later converted to getter/setter if 
>>>>> needed, without breaking calling code.
>>>>> ..
>>>>
>>>> can you give an example please.
>>>>
>>>> i.e. before (class with public member) and after ( i.e. that 
>>>> public member converted to getter/setter).
>>>
>>> Did you read the link provided? There's examples there...
>>
>> it's say for member functions, not member variables.
>>
>> I read it, but I dont get the point was being made about how 
>> use ufcs to convert a public member variable of a class type 
>> into a getter and setter. Was there an example in the link 
>> that I missed?
>
> It's actually kind of hard to wrap my head around.
>
> I will try to give you an example as to how you could convert a 
> field into a getter/setter without breaking the interface 
> between the user of the library, though it does require code 
> refactoring on your end.
>
> Say you have the class Rect2D:
>
> ```
> class Rect2D {
>     int width;
>     int height;
> }
> ```
>
> The users of your class would use it like so:
>
> ```
> Rect2D rect = new Rect2D();
> rect.width = 5;
> rect.height = 5;
> ```
>
> Say you want to write 'SET' now whenever someone sets a 
> width/height value for the rect (as an example), and 'GET' when 
> someone gets the width/height value for the rect, what you 
> could do is do this:
>
> ```
> class Rect2D {
>     int rectWidth;
>     int rectHeight;
>
>     int width() {
>         writeln("GET");
>         return rectWidth;
>     }
>
>     void width(int rectWidth) {
>         writeln("SET");
>         this.rectWidth = rectWidth;
>     }
>
>     int height() {
>         writeln("GET");
>         return rectHeight;
>     }
>
>     void height(int rectHeight) {
>         writeln("SET");
>         this.rectHeight = rectHeight;
>     }
> }
> ```
>
> Honestly, it may not be a magic bullet, but still useful.

oh. so i get it now. you have to refactor your class (change 
member variable names and also do it in all places where they are 
used througout the class. then add new methods, overloading them 
in this way and that way, all because you're initial design never 
factored in the possibility of change (or even some validation of 
the vale being returned to the client, or validation of value 
coming from the client).

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 ;-)