> > My initial reaction was that, no, we really do want IdentityObject here, > because it's useful to be able to assign an abstract class type to > IdentityObject. > > But: for new classes, the compiler will have an opportunity to be explicit. > It's mostly a question of how we handle legacy classes. And there, it would > actually be bad to infer IdentityObject, when in most cases the class will > get permits_value when it is recompiled. Probably best to avoid a scenario > like: > > - Compile against legacy API, assign library.AbstractBanana to IdentityObject > in your code > - Upgrade to newer version of the API, assignment from library.AbstractBanana > to IdentityObject is an error > > So, okay, let's say we limit JVM inference to concrete classes. And javac > will infer/generate 'implements IdentityObject' if it decides an abstract > class can't be permits_value. > > What about separate compilation? javac's behavior might be something like: 1) > look for fields, 'synchronized', etc. in the class declaration, and if any > are present, add 'implements IdentityObject' (if it's not already there); 2) > if the superclass is permits_value and this class doesn't extend > IdentityObject (directly or indirectly), set permits_value. (1) is a local > decision, while (2) depends on multiple classes, so can be disrupted by > separate compilation. But, thinking through the scenarios here... I'm pretty > comfortable saying that an abstract class that is neither permits_value nor a > subclass of IdentityObject is in an unstable state, and, like the legacy > case, it's probably better if programmers *don't* write code assuming they > can assign to IdentityObject. >
I agree that "it's probably better if programmers *don't* write code assuming they can assign to IdentityObject." We've historically assumed that separate compilation should endeavour to be consistent and if not, should live with the consequences. The best analogy I can think of is the StackOverflowError due to bridge method loops - there we tell users to fix their separate compilation issues and don't try to paper over it in the VM - and I think it's best to do the same here. Using both (1) and (2) is the right call here - no need to limit to the local information when we can make the better decision using other necessarily available classes (ie: the superclass) --Dan
