Infer Type: Known Issues

Infer Type's effect can't be undone automatically

Problem

When successful, Infer Type does several changes to a program, which are sometimes hard to trace. Unfortunately, these changes cannot be undone automatically. You can preview the changes by inspecting the type hierarchy presented in the New types dialog, but there is no preview comparable to that of other Eclipse refactorings.

Solution

perhaps sometime

Infer Type uses nonsensical supertype

Problem

Sometimes Infer Type computes a type whose inferred protocol (set of members) is identical to that of some other type already subtyped by the declaration element’s original type. In this case, Infer Type decides that the existing type should be used (and no new one introduced). However, this need not always make sense. For instance, if Infer Type computes that the inferred protocol of a declaration element is empty, it could suggest Serializable as its inferred type (even though the use of the declaration element has nothing to do with serialization and, what is much worse, many other, otherwise totally unrelated classes implement Serializable and therefore become substitutable).

Solution

Since there is no information from which Infer Type could deduce that an existing interface with the required protocol and supertypes does not reflect the intended semantics of a program (i.e., allows assignment of objects that were intentionally excluded by the original type), it will use this type. The alternative would be to introduce a new interface with the same protocol, but perhaps fewer implementing classes, which in most cases would lead to a proliferation of types (and might fail to express that two interfaces, or roles, are actually the same).

In case Infer Type computes an empty interface, it always uses Object.

Binary methods and double dispatch

Problem

A binary method is characterized by a parameter type that is the same as the receiver type, i.e., the enclosing class. If Infer Type is applied to a formal paramater of a binary method, it computes a new supertype for it, but does not move the method declaration to this supertype. The method is therefore no longer binary, at least not in the strict sense. Other than that, however, the program remains correct.

Solution

The problem dissolves if the binary method makes use of double dispatch. In this case, parameter and receiver swap roles, in whose course the parameter becomes this. Since this requires assignment compatibility of parameter and owner, the type of this must be a supertype of the parameter's type and vice versa, which implies that both must be the same.

Infer Type does not extract comments

Problem

When Infer Type moves a method declaration to a newly introduced supertype, it does not take the comments (including JavaDocs) with it. As a result, the new interfaces remain undocumented. In order not to lose these comments, Infer Type refrains from deleting the original (abstract) method declarations.

Solution

Could be done ...

Infer Type does not delete superfluous method declarations

Problem

When Infer Type moves an abstract method declaration from an abstract class or interface to a newly introduced supertype, it could delete the original declaration. However, because it currently doesn't move the comments (see above), it leaves the (now superfluous) method declarations untouched.

Solution

Could be done ...

home