5 ms·

I'm never understood why code generation for getters and setters is so over-engineered. Heavy technologies for light work is almost always more trouble than it'

I'm never understood why code generation for getters and setters is so over-engineered. Heavy technologies for light work is almost always more trouble than it's worth.

commandlinefan 5y ago
Getters are setters are pointless anyway - unless you're creating read-only properties by only providing getters, reflexively adding a getter and a setter for every property is exactly the same as just marking the property public. It's even worse in the case of immutable objects (like lists or maps), because the getter itself returns a reference to the mutable object. Getters and setters mentality came from a horrible misunderstanding of object oriented design principles and has been standardized into common practice.
- slver 5y ago
  get()/set() is the same as a public property, until you change the implementation, while maintaining interface compatibility, which is the point. In C# you'd have a point, they have parametric properties and readonly properties. So you'd favor just declaring public properties. But this is why context matters. And OO design principles also depend on this context.
  - marcosdumay 5y ago
    > until you change the implementation, while maintaining interface compatibility, which is the point How many times have you seen that done on the real world? And how many times have you seen that done, and it not creating a lot of bugs because of the behavior change without interface changes? Personally, I've seen the first one more than zero times. Not the second. Every single time somebody decided to mess with a setter or a getter, it broke the systems that depended on it, and things would have been much better if they simply changed the interface, so the problems would arrive at compile time.
    - slver 5y ago
      The behavior doesn’t change. The implementation does. Those are orthogonal. And yes I see it every day. The collection interfaces in Java have countless swappable implementations. Those are basically getters and setters on a vector. I also had to change entity storage to columnar for a project. Did that. Never had to change a line of code outside the entities.
- whatshisface 5y ago
  In languages without property support, reflexively writing getters and setters is the only way to make it possible to go back later and add logic to getting and setting without changing the callsites. Is this a workaround for the combined shackles of mismanaged enterprise environments where changing callsites is impossible for some reason, and legacy language environments where you have to use Java for some reason? Yes, of course. But sometimes you need a workaround.
  - slver 5y ago
    The real question is why is the convention getFoo() setFoo(foo) and not foo() and foo(foo).
    - whatshisface 5y ago
      Not all languages have overloading.
      - slver 5y ago
        I'm referring to Java.
        whatshisface 5y ago
        I think the pattern was adopted from languages before Java which didn't have overloading.
    - swsieber 5y ago
      It makes for easier searching in small code bases with stuff like grep instead of needing full language server / ide support.
  - commandlinefan 5y ago
    > go back later and add logic to getting and setting Which, realistically, you're virtually never going to do - at least not often enough to justify the boilerplate and especially in the case of things like "records" which were probably auto-generated from a schema (with obligatory getters and setters) anyway. If you did, you'd end up confusing all of your callers who probably wrote client code presuming that what they provided in the setter was going to be exactly what they get back in the getter.

I'm never understood why code generation for getters and setters is so over-engineered. Heavy technologies for light work is almost always more trouble than it's worth.

commandlinefan 5y ago

Getters are setters are pointless anyway - unless you're creating read-only properties by only providing getters, reflexively adding a getter and a setter for every property is exactly the same as just marking the property public. It's even worse in the case of immutable objects (like lists or maps), because the getter itself returns a reference to the mutable object. Getters and setters mentality came from a horrible misunderstanding of object oriented design principles and has been standardized into common practice.

slver 5y ago
get()/set() is the same as a public property, until you change the implementation, while maintaining interface compatibility, which is the point. In C# you'd have a point, they have parametric properties and readonly properties. So you'd favor just declaring public properties. But this is why context matters. And OO design principles also depend on this context.
- marcosdumay 5y ago
  > until you change the implementation, while maintaining interface compatibility, which is the point How many times have you seen that done on the real world? And how many times have you seen that done, and it not creating a lot of bugs because of the behavior change without interface changes? Personally, I've seen the first one more than zero times. Not the second. Every single time somebody decided to mess with a setter or a getter, it broke the systems that depended on it, and things would have been much better if they simply changed the interface, so the problems would arrive at compile time.
  - slver 5y ago
    The behavior doesn’t change. The implementation does. Those are orthogonal. And yes I see it every day. The collection interfaces in Java have countless swappable implementations. Those are basically getters and setters on a vector. I also had to change entity storage to columnar for a project. Did that. Never had to change a line of code outside the entities.
whatshisface 5y ago
In languages without property support, reflexively writing getters and setters is the only way to make it possible to go back later and add logic to getting and setting without changing the callsites. Is this a workaround for the combined shackles of mismanaged enterprise environments where changing callsites is impossible for some reason, and legacy language environments where you have to use Java for some reason? Yes, of course. But sometimes you need a workaround.
- slver 5y ago
  The real question is why is the convention getFoo() setFoo(foo) and not foo() and foo(foo).
  - whatshisface 5y ago
    Not all languages have overloading.
    - slver 5y ago
      I'm referring to Java.
      - whatshisface 5y ago
        I think the pattern was adopted from languages before Java which didn't have overloading.
  - swsieber 5y ago
    It makes for easier searching in small code bases with stuff like grep instead of needing full language server / ide support.
- commandlinefan 5y ago
  > go back later and add logic to getting and setting Which, realistically, you're virtually never going to do - at least not often enough to justify the boilerplate and especially in the case of things like "records" which were probably auto-generated from a schema (with obligatory getters and setters) anyway. If you did, you'd end up confusing all of your callers who probably wrote client code presuming that what they provided in the setter was going to be exactly what they get back in the getter.