4 ms·

I don’t fault Java programmers for their “love” of getters/setters; they’re taking something that really is a best-practice in certain situations, and which mos

by derefr 6y ago

I don’t fault Java programmers for their “love” of getters/setters; they’re taking something that really is a best-practice in certain situations, and which mostly doesn’t hurt otherwise (that best-practice being “making the contractual interface for an object its methods, so that the implementation can change while the interface remains stable”) and just deciding to do it all the time rather than only when it will likely have future benefits. Which makes a lot of sense, if you look at it through the lens of cultural anthropology. Enterprises dictate approaches like this, because the alternative is leaving the choice to the individual programmer — and these same enterprises don’t hire experienced-enough programmers to trust their judgement. And so all the programmers who work for these enterprises end up absorbing this approach as a social norm, just “something you do”, rather than “independently rediscovering the need for it” in a way that would lead to them actually knowing when it’s useful. So, even when not locked into an enterprise that forces it on them, they just keep doing it, because that’s the culture that’s been inculcated on them (and how all the examples look, how all the libraries do it, etc.) Personally, I’m not in theory against “unilateral” use of getters/setters, either. I just kind of which they worked in Java the way they work in Ruby: where referencing a field on any object other than `this` would actually just be sugar for a call to the getter/setter. Where the Java optimizer would then take special care to optimize-away the call frame for known-‘trivial’ getters/setters.

The_rationalist 6y ago
This is why Kotlin has the best of both worlds. You can access a variable through A.b and it will automatically call the getter if there's one
- mgkimsal 6y ago
  groovy did/does this too. any property automatically has a getter/setter in the compiled code if an explicit getter or setter doesn't exist.
- kabes 6y ago
  Javascript can do the same, but I think it's an anti pattern, since now the caller doesn't know what side effects, or performance characteristics you get by accessing the property with an implicit getter/setter.
  - dragonwriter 6y ago
    > now the caller doesn't know what side effects, or performance characteristics you get by accessing the property with an implicit getter/setter. Beyond method call overhead (which may or may not be a given depending on how things are optimized in some languages), the caller doesn't know that automatically with explicit getters/setters, either; you'd have to read the source to know that just as much if they are explicit as implicit (or rely on documentation, which hopefully is complete and current).
- augustk 6y ago
  In the programming language Eiffel this is called the uniform access principle.
  - edflsafoiewq 6y ago
    The uniform access principle is that features are "available through a uniform notation, which does not betray whether they are implemented through storage or through computation"; it doesn't imply anything about what the uniform notation is. Java-style getters/setters also achieve the uniform access principle; everything is accessed only via get_X()/set_X() and never a raw field .X that would betray it was implemented through storage.
    - augustk 6y ago
      "Although it's a fundamental feature of object-oriented programming, remarkably few OO languages really follow it. (Eiffel is naturally an exception.) Most languages simulate it by convention, hence the habit of using accessors such as getAge in Java and C++ programs." https://martinfowler.com/bliki/UniformAccessPrinciple.html https://martinfowler.com/bliki/UniformAccessPrinciple.html
nsxwolf 6y ago
Is anyone not using Lombok these days? I haven’t written a getter or a setter in years.
- pjmlp 6y ago
  I never used and never plan to. Don't need bytecode magic that my IDE can do for me.
  - rufus_foreman 6y ago
    I'm not a fan but the place where I work now uses it and it doesn't bother me as much as I thought it would. IDEs are smart enough to work with it. Although I still wouldn't use it on a project of my own.
  - nsxwolf 6y ago
    A bean with nothing but fields and a couple annotations is much cleaner and smaller than one full of generated getter/setter code. And I can rename a field without having to fumble around with the IDE to regenerate them.
    - pjmlp 6y ago
      Never learned to use code navigation tools and respective IDE filters?
      - nsxwolf 6y ago
        Those aren’t as good as just using Lombok.
        pjmlp 6y ago
        Indeed, they don't provide the pleasure to dig out bugs caused by mishandling bytecodes or the verifier.
      - petersellers 6y ago
dkarl 6y ago
Yeah, I think it's no accident that the best thing about working on the JVM is the massive ecosystem of popular libraries. Java and the Java community did a pretty good job of solving the problem of extremely large numbers of developers sharing code with little coordination over long timelines. Unfortunately, they did it because that was their vision of how enterprise software would be created: dozens if not hundreds of programmers working together on enormous monolithic applications with months-long release cycles. Your code had to be extremely defensive, so you could change the internals without fear, and also extensible and customizable, so you would be less likely to be interrupted by requests to make changes to support someone else's work. All the extra work and complexity to accomplish that became the "right" way to write Java code regardless of context.
jrochkind1 6y ago
I was thinking of ruby as you write this... it's not quite true that in ruby "referencing a field on any object... is just sugar for a call to the getter/setter." It's actually true that ruby makes it impossible to directly access fields in objects other than `self` (ie `this`). Seriously, it's not possible ruby takes away the ability to do so, thereby making it not even a choice anymore, you have to create a getter/setter, it's the only option. There is no sugar, there is simply a prohibition on direct access to iVars in other objects, period. What might make it look like "sugar" is that parentheses method calls are optional in ruby -- `obj.foo` is just another syntax for `obj.foo()` Whether or not it's a getter, any method at all, nothing special for getter/setter here. That's literally the only thing going on here that makes you think there is "sugar", ruby syntax having parentheses be optional in method calls. And additionally ruby gives you a shortcut "macro" to defining the getter/setter, `attr_accessor :foo` inside a class body just automatically defines the conventional getter and setter for you. You still do need to define them though, again no "sugar". So ruby actually comes down solidly on the side of "yes, always use getters/setters"... in some ways this is what you are complaining about, people always doing it, right? But it turns out differently and not annoying anyone, I think, because it was planned for by the language designers in the first place, both by making it mandatory (eliminating it as a point of debate or as something a programmer will spend any time ever considering when implmeenting), and by providing devices to make it convenient. I think the choice to make parentheses optional in method calls actually goes along with the choice to forbid direct access to fields in other objects; both because there is now no need to syntactically distinguish between the two, and because it makes it less annoying to forbid. It also causes all sorts of other complexity in writing parsers for ruby though...
- derefr 6y ago
  I happen to know a bit about Ruby. (A lot more than I know about Java, as it happens.) Let me pick a few nits :) #instance_variable_get / #instance_variable_set is a thing. The (default) implementations of these methods on Object are just C code that do direct IVar reads/writes. You can thus think of #instance_variable_get and #instance_variable_set as real “field access” in Ruby. It’s just that, unlike most languages, there is sugar† for the getter/setter, and there isn’t any sugar for the “direct” field access. † (The setter’s sugar is obvious — `a.b=x` is re-written by the lexer into a call `a.send(:"b=", x)`. The getter’s sugar is less obvious — it’s seemingly just a regular method call. But think about why Ruby makes parens optional on arity-0 method calls in the first place. To sweeten getters into something field-access-looking!) But, well, you might say, #instance_variable_get is just a method, too! I can override it as I want! Really, it’s just another kind of getter/setter — sort of a categorical one. Well, let’s go one level deeper — you can literally “reach into” the object to take a look at its IVars as it sees them: obj.instance_eval{ @foo } “Objection! #instance_eval can be overridden! DRb proxy-objects do it!” Well, okay, let’s get creative, and start breaking through the seemingly pure-OOP semantics of Ruby, revealing the more functional-language underpinnings: inst_eval_fn = Object.instance_method(:instance_eval) inst_eval_fn.bind(obj).call{ @foo }

by derefr 6y ago

The_rationalist 6y ago

This is why Kotlin has the best of both worlds. You can access a variable through A.b and it will automatically call the getter if there's one

mgkimsal 6y ago
groovy did/does this too. any property automatically has a getter/setter in the compiled code if an explicit getter or setter doesn't exist.
kabes 6y ago
Javascript can do the same, but I think it's an anti pattern, since now the caller doesn't know what side effects, or performance characteristics you get by accessing the property with an implicit getter/setter.
- dragonwriter 6y ago
  > now the caller doesn't know what side effects, or performance characteristics you get by accessing the property with an implicit getter/setter. Beyond method call overhead (which may or may not be a given depending on how things are optimized in some languages), the caller doesn't know that automatically with explicit getters/setters, either; you'd have to read the source to know that just as much if they are explicit as implicit (or rely on documentation, which hopefully is complete and current).
augustk 6y ago
In the programming language Eiffel this is called the uniform access principle.
- edflsafoiewq 6y ago
  The uniform access principle is that features are "available through a uniform notation, which does not betray whether they are implemented through storage or through computation"; it doesn't imply anything about what the uniform notation is. Java-style getters/setters also achieve the uniform access principle; everything is accessed only via get_X()/set_X() and never a raw field .X that would betray it was implemented through storage.
  - augustk 6y ago
    "Although it's a fundamental feature of object-oriented programming, remarkably few OO languages really follow it. (Eiffel is naturally an exception.) Most languages simulate it by convention, hence the habit of using accessors such as getAge in Java and C++ programs." https://martinfowler.com/bliki/UniformAccessPrinciple.html https://martinfowler.com/bliki/UniformAccessPrinciple.html

nsxwolf 6y ago

Is anyone not using Lombok these days? I haven’t written a getter or a setter in years.

pjmlp 6y ago
I never used and never plan to. Don't need bytecode magic that my IDE can do for me.
- rufus_foreman 6y ago
  I'm not a fan but the place where I work now uses it and it doesn't bother me as much as I thought it would. IDEs are smart enough to work with it. Although I still wouldn't use it on a project of my own.
- nsxwolf 6y ago
  A bean with nothing but fields and a couple annotations is much cleaner and smaller than one full of generated getter/setter code. And I can rename a field without having to fumble around with the IDE to regenerate them.
  - pjmlp 6y ago
    Never learned to use code navigation tools and respective IDE filters?
    - nsxwolf 6y ago
      Those aren’t as good as just using Lombok.
      - pjmlp 6y ago
        Indeed, they don't provide the pleasure to dig out bugs caused by mishandling bytecodes or the verifier.
    - petersellers 6y ago

dkarl 6y ago

Yeah, I think it's no accident that the best thing about working on the JVM is the massive ecosystem of popular libraries. Java and the Java community did a pretty good job of solving the problem of extremely large numbers of developers sharing code with little coordination over long timelines. Unfortunately, they did it because that was their vision of how enterprise software would be created: dozens if not hundreds of programmers working together on enormous monolithic applications with months-long release cycles. Your code had to be extremely defensive, so you could change the internals without fear, and also extensible and customizable, so you would be less likely to be interrupted by requests to make changes to support someone else's work. All the extra work and complexity to accomplish that became the "right" way to write Java code regardless of context.

jrochkind1 6y ago

I was thinking of ruby as you write this... it's not quite true that in ruby "referencing a field on any object... is just sugar for a call to the getter/setter." It's actually true that ruby makes it impossible to directly access fields in objects other than `self` (ie `this`). Seriously, it's not possible ruby takes away the ability to do so, thereby making it not even a choice anymore, you have to create a getter/setter, it's the only option. There is no sugar, there is simply a prohibition on direct access to iVars in other objects, period. What might make it look like "sugar" is that parentheses method calls are optional in ruby -- `obj.foo` is just another syntax for `obj.foo()` Whether or not it's a getter, any method at all, nothing special for getter/setter here. That's literally the only thing going on here that makes you think there is "sugar", ruby syntax having parentheses be optional in method calls. And additionally ruby gives you a shortcut "macro" to defining the getter/setter, `attr_accessor :foo` inside a class body just automatically defines the conventional getter and setter for you. You still do need to define them though, again no "sugar". So ruby actually comes down solidly on the side of "yes, always use getters/setters"... in some ways this is what you are complaining about, people always doing it, right? But it turns out differently and not annoying anyone, I think, because it was planned for by the language designers in the first place, both by making it mandatory (eliminating it as a point of debate or as something a programmer will spend any time ever considering when implmeenting), and by providing devices to make it convenient. I think the choice to make parentheses optional in method calls actually goes along with the choice to forbid direct access to fields in other objects; both because there is now no need to syntactically distinguish between the two, and because it makes it less annoying to forbid. It also causes all sorts of other complexity in writing parsers for ruby though...

derefr 6y ago
I happen to know a bit about Ruby. (A lot more than I know about Java, as it happens.) Let me pick a few nits :) #instance_variable_get / #instance_variable_set is a thing. The (default) implementations of these methods on Object are just C code that do direct IVar reads/writes. You can thus think of #instance_variable_get and #instance_variable_set as real “field access” in Ruby. It’s just that, unlike most languages, there is sugar† for the getter/setter, and there isn’t any sugar for the “direct” field access. † (The setter’s sugar is obvious — `a.b=x` is re-written by the lexer into a call `a.send(:"b=", x)`. The getter’s sugar is less obvious — it’s seemingly just a regular method call. But think about why Ruby makes parens optional on arity-0 method calls in the first place. To sweeten getters into something field-access-looking!) But, well, you might say, #instance_variable_get is just a method, too! I can override it as I want! Really, it’s just another kind of getter/setter — sort of a categorical one. Well, let’s go one level deeper — you can literally “reach into” the object to take a look at its IVars as it sees them: obj.instance_eval{ @foo } “Objection! #instance_eval can be overridden! DRb proxy-objects do it!” Well, okay, let’s get creative, and start breaking through the seemingly pure-OOP semantics of Ruby, revealing the more functional-language underpinnings: inst_eval_fn = Object.instance_method(:instance_eval) inst_eval_fn.bind(obj).call{ @foo }