Limited Visibility

When driving my car I do not like foggy weather with limited visibility. In programming languages it is the other way round: Too much detail visibility will hinder evolution of software systems. Unfortunately Java is rather weak in controlling visibility. Scala improves the situation a little bit.

Usually one uses the term "information hiding" to describe the technique of limiting the visibility of implementation details to users of software components / libraries. The Booch book [reference to be added] has nice pictures of a cat from the view of the user (grandma: purr, purr) and the implementor (gears and levers). Information hiding is very important for two reasons. First, it makes it easier to use functionality because the API is more clearly defined. Second, the provider of functionality can change implementation details more easily without fearing to break client code.

Unfortunately Java's visibility model is not that helpful in practice. You can limit visibility to the class itself (private), the same package (not subpackages or sibling packages), to more specific classes in the inheritance hierarchy (protected) or to make the class or its element world visible (public). Interface methods are always public.

It is not practical in larger Java programs to make only a facade of a larger software system or library visible and to define limited visibility between the parts of the software system. A typical scenario is that you have a structure of packages that use helper functions from a utility package. The utility functions are not useful in a context outside this package structure. But Java cannot prevent client software to use the helpers from the utility package. Only convention can try to do this and external tools can emit warnings.

Scala discards the "package friendly" or default visibility of Java and lets the programmer specify to which level of enclosing scope an element is visible, giving more control than possible in Java. Another interesting feature is that you can restrict access to the same object (as opposed to the same class).

package chb13.fooapp

package processing {
  class FooProcessing {
    def foo {
      chb13.fooapp.utils.FooHelper.onlyForFriends
    }
  }
}

package utils {
  private [fooapp] object FooHelper {
    def onlyForFriends {
        System.out.println("psst...")
    }
  }
}

Note the access from FooProcessing.foo to FooHelper.onlyForFriends. A method from chb13.bar.BarProcessing would not have access to FooHelper methods.

Note also that there is another package declaration syntax possible in Scala as used above. You can nest package declarations and define classes and objects in several packages in the same source file. My opinion on this feature is, that it is only useful for presentations and documentation like this. In real software systems where you need packages to group and organize functionality you should not have different packages in the same file. The situation may change when we move to repository based software development environments and give up files to organize source code, but I do not see this coming in the near future.

Less spectacular and known from many languages: You can rename members on import, resolving name conflicts without having to resort to fully qualified class names. It is also possible to place imports more flexibly than in Java. Rewriting part of the previous example, we could give our helper method a shorter name that is also more meaningful in the given context:

package processing {
  class FooProcessing {
    def foo {
      import chb13.fooapp.utils.FooHelper.{onlyForFriends => psst}
      psst
    }
  }
}

Conclusion

When first introduced to Java I always was a little bit put off by the fact that you could access almost every class from everywhere using fully qualified names, even without declaring access in a file preamble.

Scala in principle still has this possibility, but only if you do not use the access qualifiers to limit visibility. The combination of the access qualifiers and the more flexible syntax for imports allows the provider of some functionality to limit access to internals and therefore ensuring better maintainability and at the same time allows for the clients to access the published functionality using names of their choice.

By the way: I didn't forget the other two languages. XSLT is currently on hold until I receive a book on it (ordered, but not delivered, yet). Groovy will get a blog entry real soon now. And Scala deserves at least one negative ^H^H^H less positive entry in the near future, but its weaker points are harder to describe...