Here it is, converted to java. You tell me which is more verbose.
public class Foo
int bar;
public Foo(int bar) {
this.bar = bar;
}
public int getBar() {
return bar;
}
public static void main(String[] args) {
System.out.println(new Foo(42).getBar());
}
}
You should make bar private, and add a setter. After all, we might want to change the rules on setting bar sometime, and you wouldn't want to have to go back and change everywhere that accesses it...
It's package-access by default, that's enough to hide it from the third-party users of the class.
> and add a setter
The original code uses `attr_reader` which defines a readonly "property". The Java translation is a single getter, with no way to set the value from outside the class.
1. bar's visibility is package local, so your code is already broken, bar is invisible outside its package
2. let's say you solve this conundrum by making the field public
2.1. This piece of code is now frozen solid, you will not be able to ever refactor it (where refactoring is defined as changing implementation without changing behavior) since you can not transparently swap fields and methods in Java
2.2. This piece of code is dead to abstract types, as fields can not be part of interfaces in Java.
2.3. This piece of code is incompatible with Java Beans and will therefore be unusable in e.g. JSP taglibs
JSP taglibs? wtf are you talking about. I'm in no way defending the idiocy of 'enterprise java'.
and your other points don't really make any sense at all. There is no such thing as 'fozen solid code'. Unless you're interfacing to external libraries etc and have agreed on a specific API, which is unlikely to include "yeah just reference 'bar' directly" unless you're insane.
