3 ms·

At the top of your post you forgot the getter for the foo field so the Java version is even longer...

axod 17y ago
getters != java. Just because some frameworks choose to use getters/setters, it doesn't make them any part whatsoever of the language. Once again, people getting confused about what Java the language is.
- jrockway 17y ago
  People like getters and setters because they provide structured and consistent access, and decouple consumers from the internal implementation of your class. If you have a "get_foo" method in your class, you can change what "foo" is under the hood without consumers knowing. If they touch the field directly, you can never change that -- your implementation becomes the interface. And the idea of OO (and good programming in general) is to avoid that. You keep talking about "ignore Java's syntax and focus on being a better programmer", but I think if you use fields for your public interface, you are compromising the quality of your code. You should be able to have the protection that getters and setters afford without the cost of typing them into every class that needs them. That would allow the "better programmer" to write a better program.
  - axod 17y ago
    >> "you can never change that" It's not really rocket science to do a search+replace. Getters+Setters have their place, where you may need to change things under the hood definitely. But most of the Java I see using them is just complete overuse of them for the sake of it. FWIW, I only use getters+setters when I need to - eg they do something other than just get/set a variable. I think it makes for clean concise readable code.
    - jrockway 17y ago
      But you agree that you are compromising flexibility to make Java less painful.
      - axod 17y ago
        No, I disagree. If I need to add a getter/setter so that it does something other than just access a field, I'll add that code at the point I need it. It's not efficient to always use setters/getters, even if the language provides them. The only sorts of things I find painful in Java is writing a class to do Comparator etc, but the number of times you need to do that can be counted on one hand. Some people who write Java astonish me with their churning out of toString, equals, hashcode, getters, setters. Checkout a few open source projects and you'll see a whole set of files defining interfaces, then a whole mirror set of source files defining the implementation of that. Which is just ridiculous when there is only 1 implementation of everything. Makes the mind boggle, but often it's an IDE churning out autogenerated code (Does that still count as Java? ;) )
        jrockway 17y ago
        This is a good technique for libraries. Decoupling interface and implementation makes flexibility the default. If components only speak an interface to each other, it is easy to substitute them in the future. The problem with Java is that the interfaces are usually useless. Imagine you have a build backend talking to a stoplight (red/green widget). The logical interface is for the builder to emit success or failure, and for the stoplight to internally change that to red or green. But of course, many people decide that the build backend should emit red or green, and that the stoplight widget should display that color. So while the build backend isn't coupled to an implementation in theory ("it just uses the RedOrGreenShowable interface!"), it actually is. Programmers....
- Hexstream 17y ago
  1. The above implementation was clearly intended to include a getter, since a class with only a private field and no way to access it doesn't make sense... 2. Using getters for properties is "idiomatic" Java, or at least it was last I used Java a few years ago... 3. More importantly, here we're comparing equivalent code in different languages and the lisp code specified a reader so I think it's only fair that the Java version should have the equivalent getter.
jrockway 17y ago
Yeah, I just noticed that. Too late to edit, unfortunately.

axod 17y ago

getters != java. Just because some frameworks choose to use getters/setters, it doesn't make them any part whatsoever of the language. Once again, people getting confused about what Java the language is.

jrockway 17y ago
People like getters and setters because they provide structured and consistent access, and decouple consumers from the internal implementation of your class. If you have a "get_foo" method in your class, you can change what "foo" is under the hood without consumers knowing. If they touch the field directly, you can never change that -- your implementation becomes the interface. And the idea of OO (and good programming in general) is to avoid that. You keep talking about "ignore Java's syntax and focus on being a better programmer", but I think if you use fields for your public interface, you are compromising the quality of your code. You should be able to have the protection that getters and setters afford without the cost of typing them into every class that needs them. That would allow the "better programmer" to write a better program.
- axod 17y ago
  >> "you can never change that" It's not really rocket science to do a search+replace. Getters+Setters have their place, where you may need to change things under the hood definitely. But most of the Java I see using them is just complete overuse of them for the sake of it. FWIW, I only use getters+setters when I need to - eg they do something other than just get/set a variable. I think it makes for clean concise readable code.
  - jrockway 17y ago
    But you agree that you are compromising flexibility to make Java less painful.
    - axod 17y ago
      No, I disagree. If I need to add a getter/setter so that it does something other than just access a field, I'll add that code at the point I need it. It's not efficient to always use setters/getters, even if the language provides them. The only sorts of things I find painful in Java is writing a class to do Comparator etc, but the number of times you need to do that can be counted on one hand. Some people who write Java astonish me with their churning out of toString, equals, hashcode, getters, setters. Checkout a few open source projects and you'll see a whole set of files defining interfaces, then a whole mirror set of source files defining the implementation of that. Which is just ridiculous when there is only 1 implementation of everything. Makes the mind boggle, but often it's an IDE churning out autogenerated code (Does that still count as Java? ;) )
      - jrockway 17y ago
        This is a good technique for libraries. Decoupling interface and implementation makes flexibility the default. If components only speak an interface to each other, it is easy to substitute them in the future. The problem with Java is that the interfaces are usually useless. Imagine you have a build backend talking to a stoplight (red/green widget). The logical interface is for the builder to emit success or failure, and for the stoplight to internally change that to red or green. But of course, many people decide that the build backend should emit red or green, and that the stoplight widget should display that color. So while the build backend isn't coupled to an implementation in theory ("it just uses the RedOrGreenShowable interface!"), it actually is. Programmers....
Hexstream 17y ago
1. The above implementation was clearly intended to include a getter, since a class with only a private field and no way to access it doesn't make sense... 2. Using getters for properties is "idiomatic" Java, or at least it was last I used Java a few years ago... 3. More importantly, here we're comparing equivalent code in different languages and the lisp code specified a reader so I think it's only fair that the Java version should have the equivalent getter.

jrockway 17y ago

Yeah, I just noticed that. Too late to edit, unfortunately.