Friday Inteview Question: Custom Visibility Scopes

We do hiring interviews on Open Source Fridays. Most of a candidate's time is spent on pair programming, whiteboarding, and giving a presentation to the team. Here is an example question from a whiteboarding session:

Background: Mark Watson has proposed a simple solution for packaging Java libraries to be IDE-friendly:

users of these libraries (mostly just me :-) only want the highest level APIs to show in popup completion lists and the entire set of implementation classes remain invisible. The solution is easy: a public API class with implementation classes in the same package with package-ony (i.e., neither public or private) visibility.

Mark is cleverly combining the existing visibility mechanisms, plus creating an extra class, to trick IDEs into exposing the right methods for IDE completion.

To generalize this solution, we would need to

  • create a named abstraction that solves the problem
  • hide the "how" details behind the new abstraction

In this case the new abstraction we need is a custom visibility scope. Java provides four scopes: public, private, protected, and {package}. We want to add new scopes with names like TopLevelAPI. One can imagine many ways to do this in Java. Here are a few obvious ones, building on existing idioms:

  • Define an annotation, e.g. public @TopLevelAPI myMethod()
  • Define an external class that extends Java reflection. (The JavaBeans API is a perfect example of this. JavaBeans create a custom class member type, property, that augments the existing constructors, methods, and fields.)

In Ruby, you could create a custom visibility scope using object-oriented design. Pick a base class for all classes that need the custom scope. Define a class method named for the scope, e.g.

  def self.top_level_api_instance_methods
    # TODO: return array of top level methods
    # TODO: declarative helper?
  end

You could reopen Class to provide this feature for all classes. (Rails provides a good example of a domain-specific custom visibility scope, with a slightly different implementation. The assigns are a special scope for controller fields that are automatically visible to the view.)

Questions:

  1. The three approaches outlined above would all require IDE collaboration. Compare and contrast the approaches from the point-of-view of an IDE vendor charged with supporting them.
  2. The approaches above also require that developers mark certain methods as TopLevelAPI. Compare and contrast the approaches in terms of the work a developer does to take advantage of them.

We are hiring. If you are interested, send us your thoughts on the questions above, or post them in the comments.

Get In Touch