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