A Case for Properties: Programming Language Design

Re:A Case for Properties: Programming Language Design by mrkeen on Sunday November 15, 2020 @03:16PM (#25104403)

I'm with you. I also enforced getters-and-setters back in the day, for no good reason.

If you're worried about long diffs because you changed many calls from '.x' to '.getX()', good. If it's so coupled that it's called in a thousand places, and you just changed functionality, it's on you to understand those thousand places. If it doesn't affect those places - which you don't know unless you look - then don't make the change.

As for the RgbColor example in the article, not using setters would be better.

    RgbColor red = new RgbColor(1,0,0);
    red.set(.., .., ..);
    // Is it still 'red'?

[ Parent | on HN ]

Re:A Case for Properties: Programming Language Design by WillBAnders on Sunday November 15, 2020 @08:39PM (#25107002)

With the RgbColor example, a language that has mutability permissions (like Rhovas) resolves this easily. If you don't have mutable access to the object, setters can't be used.

[ Parent | on HN ]