5 ms·

Ah I didn't realize Ruby does not have the ability to access properties of an object. That seems like a pretty big disadvantage.

• Twisol 16y ago
  That's because methods effectively -are- properties. See: class Foo attr_reader :bar def initialize (num) @bar = num end end puts Foo.new(42).bar attr_reader is a class-level method that defines a getter method for the named variable. There's also attr_writer, for setting, and attr_accessor, for both at once.
  • axod 16y ago
    ... and people complain that Java is verbose???
    • ZitchDog 16y ago
      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()); } }
      • slashdot 16y ago
        Actually, in idiomatic java, it'd be even longer: 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...
        • masklinn 16y ago
          > You should make bar private 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.
      • axod 16y ago
        That's not really true. Why would you need a getBar() method in Java? public class Foo int bar; public Foo(int initBar) { bar = initBar; } public static void main(String[] args) { System.out.println(new Foo(42).bar); } }
        • masklinn 16y ago
          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
          • axod 16y ago
            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.