Hacker News Reader

Comment by Twisol | Hacker News Reader

With regards to differentiating methods, that's simple. "obj.name" calls a method. An object's variables are hidden inside the object, so the only way to access them is via methods anyways.

Furthermore, variables can't be called. If you have a proc object in a variable, you use "myproc.call" to invoke it. The only ambiguity is between methods call within the same 'self' and local variables:

    def foo
      42
    end
    
    def bar
      puts foo #=> 42
      foo = 30
      puts foo #=> 30
      puts self.foo #=> 42
    end

In practice this isn't a big problem.

View on HN

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

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.

... and people complain that Java is verbose???

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());
      }
    }

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...

> 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.

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);
      }
    }

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.

Reply on news.ycombinator.com