Lambda the Ultimate

enum VALUES { ... }
void foo(VALUES v);

is extended by:

enum VALUES2 : public VALUES { ... }
void foo2(VALUES2 v);

foo works the same way as before, accepting only values it can handle, while foo2 can handle the original values and new values.

The obvious problem is the "fragile base class" issue. That is, what happens if VALUE is extended to include new values. If we are lucky the new values added to VALUES will conflict with existing values in VALUES2 and we get a compile error. If we are unlucky foo2 may receive argument values it doesn't know how to handle.

Still, the fragile base class is an issue with all types of implementation inheritance and not specific to this case.

Or have I misunderstood? :o)

Consider a class D derived from a class B. Java allows a reference to an object of type D to be used wherever a reference to an object of type B is expected. Using a reference to B where a reference to D is expected requires an explicit cast, and can result in a run-time exception if the object is not the correct type.

Given my previous example, Java should allow an automatic conversion from a value of type VALUES to a value of type VALUES2, because VALUES is a subset of VALUES2. The reverse conversion should require a cast, and result in a run-time exception if the value does not belong to the VALUES set. I don't know if Java 1.5 implements this feature in this way.

This is sort of related to Tim Sweeney's posts on type theory.

More seriously, it's not as bad as I first thought. I think the reflex horror is largely based on using null as the empty list, but it doesn't work that way in Java - an empty iterator is empty (it doesn't return null) (as I'm sure you know). But even so. I guess they don't have any DB people on their team (I've just been reading one of Celko's books on SQL - not as good as I'd expected, does anyone know of anything better? (don't ask "better in what way?" - you know if a book is good)). While I don't think it will do much harm (apart from looping over result sets from SQL), I can't think of any example where it would be useful. Is there some part of Swing, say (I don't do Java GUI much), that is helped by assuming null implies zero?

They basically just codified the current idea of best practices. I bet that if they gave any thought at all to the idea of allowing implicit upcasting (instead of implicit downcasting), that they dismissed it as being too weird.

Besides, changing the behavior of implicit casts would have required a change to the vm's bytecode verifier. Java 1.4 already broke bytecode compatibility, and nobody would have tolerated it happening again in 1.5. Also, requiring changes to the verifier suggests that implicit upcasting might open up security holes in some situations.

I suspect that most companies will simply decide that extending an enum is bad, and just ban it in their style guides.

XML Schema has a notion of subtyping like this. Basically, if you have a type X (which is a regular expression) which involves a choice, then you can declare any type Y which fixes that choice to be a subtype. For example, if X is:

author*, title, year

and Y is:

author, title, year

then Y can be declared to be a `restriction' of Y, since author* is type-equal to (1|author+), so it fixes a choice. (`1' is the empty sequence.)

I found this rather interesting; you might call it `additive' subtyping in contrast to the usual notion of subtyping where you extend a record, which might be called `multiplicative' subtyping. You can model these subtyping relations via coercions: additive refinements are modeled by injections of sums and multiplicative ones by projections of products.

From the point of view of the Nice language, all this confusion seems to result from Java's (and other language's) inability to express possibly-null and non-null types. For instance, when you have a Map<String, int> map, then map.get(key) has type ?int. That is, the value is either an int, or null if there is no mapping for that key. Therefore, you need to test this result against null before treating it as an int. Consequently, the type system guarantess that you never get NullPointerException.

Nice also has the x || y operator: if x has type ?T and y has type T, then x || y has type T. It evaluates to the value of x, unless it is null, in which case it has the value of y. So in their example you could simply write map.get(key) || 0, which has type int.

I think it's absolutely as bad as I first thought! Using Integer objects with null is a pretty common idiom in Java to implement functionality like ML's 'a option type or Haskell's Maybe a type. Having null automatically converted to 0 makes this awkward at best, maybe impossible. Imagine the reaction if Simon Peyton Jones announced that in the next version of Haskell, Maybe Int and Int would be equivalent, and NONE would be considered equal to 0...

To launch something of a tangent, the real problem exposed here is that using null in this way is evil, and a much nicer (and still very OO) solution would be to define a MaybeInt class for this purpose (or, with generics, the much more useful Maybe<*>). Unfortunately, class definition is too heavyweight for this, inner classes are ugly, and performance-conscious people tend to be enormously wary of creating "spurious" wrapper objects. This, in my opinion, is the much more serious problem with Java, and the one also manifested in the int/Integer distinction. It's quite awful to have an object-oriented language that discourages you from using objects... Imagine a functional language in which you were told, in all seriousness, to try to avoid defining too many functions!

(In the current implementation, wrappers are used, but only for primitive values.)

Hi. I glanced at your blog article regarding my recent interview on java.sun.com. I just wanted to correct one misconception and provide one update:

The enum feature, as currently construed, will *not* allow inheritance, for precisely the reason that people discussed: the "inverted inheritance relationship" is too confusing to programmers. There are a number of other technical complications too. In the final analyisis, we felt the costs far outweighed the benefits.

Regarding auto-unboxing of null to zero, people overwhelmingly told us not to do this, so we almost certainly won't.

OTOH,

the "inverted inheritance relationship" is too confusing to programmers.

Is that the reason, or, as Kimberley pointed out:

changing the behavior of implicit casts would have required a change to the vm's bytecode verifier. Java 1.4 already broke bytecode compatibility, and nobody would have tolerated it happening again in 1.5

Probably both I guess ...