On Saturday, 19 November 2022 at 03:19:53 UTC, {}() wrote:

Did you read the link provided? There's examples there...

On Saturday, 19 November 2022 at 03:22:12 UTC, thebluepandabear wrote:

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?

On Saturday, 19 November 2022 at 03:39:18 UTC, {}() wrote:

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.

On Saturday, 19 November 2022 at 03:39:18 UTC, {}() wrote:

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

classes, and as such you will have a good chunk of code that is practically useless and doing nothing.

These days with modern IDEs it takes a second to change the name of a variable globally. In production level code, it may take more time, but I doubt by a lot.

Think about it, if you have a class with 20 different variables that don't need any special rules to access, think about the amount of code you would have to add for getters/setters. Now in production level code you will have thousands of these classes, and as such you will have a good chunk of code that is practically useless and doing nothing.

On Saturday, 19 November 2022 at 04:19:01 UTC, thebluepandabear wrote:

By making your class member variables public, it is not clear whether you forgot that you needed to validate incoming and outgoing values, or whether you don't need to do this (not ever).

If you did it because of the former, you're fired ;-)

If you did it because of the latter, you're also fired ;-)