Hacker News Reader

Comment by mises | Hacker News Reader

Classes being Java's only translation units are one of the downsides that I'm mentioning. Really my objection is more that it doesn't allow use of the right tool for the job (which is not always an object).

View on HN

I'm not sure I see where objects enter into this. I mean, you seem to be asking for something like this,

  public unit Util {
      public void foo() {
          // do things
      }
  }

which would compile down into a bytecode-containing artifact which we could call a unit file, which the JVM would load at runtime using some sort of unit loader. Callers could import the Util unit and then invoke foo with the statement

  Util.foo();

But then, I don't see the diffence between the above and the following,

  public class Util {
      public static void foo() {
          // do things
      }
      // If we're really pedantic, we can ban construction of Util instances
      private Util() {}
  }

which compiles down into a bytecode-containing artifact called a class file, which the JVM loads at runtime using a class loader. Callers can import the Util class and then invoke foo with the statement

  Util.foo();

What's this downside you speak of? Is there something a different kind of translation unit would do that a class currently doesn't?

There's no 'object' involved here. First you said this requires subclassing, which it doesn't. Now you're handwaving about a feature that's specifically there to allow for things like plain global functions - a static method has no instance, there's no dynamic dispatch and it can't be overridden. People often point out the facility's utter un-OO-ness. The OO equivalent would be a class method which Java doesn't support at all.

Reply on news.ycombinator.com