Bug 356706

Description Knut Wannheden 2011-09-05 02:04:14 EDT

As discussed in the newsgroup (see http://www.eclipse.org/forums/index.php/m/719805/) there are a few use cases (see below and newsgroup thread for details) where the strategy of ComposedSwitch for locating the appropriate switch to delegate to doesn't work as desired. Neither is the class extendable in such a way that a corresponding strategy could be implemented in client code.

The use case is the following: I have a ComposedSwitch with which I've registered a switch for a package 'a' containing a class A and a sub class AA. Now client code calls doSwitch(EObject) on an instance of a type BB of another package 'b', which has the super types b:B and a:A (in that order). The method ComposedSwitch#doSwitch(EClass, EObject) will simply call itself recursively for the *first* super type of the given class if no delegate has been registered for the type's EPackage, so in the example we would end up in the ComposedSwitch's defaultCase() and not in caseA() of the delegate for 'a'.

It would be nice if ComposedSwitch declared a protected method to encapsulate the call to doSwitch(EClass, EObject) of one of its delegates, as that method is protected and cannot be called by a subclass of ComposedSwitch. E.g. something like delegateDoSwitch(Switch<T>, EClass, EObject).

Further I think it should be considered if the default strategy of ComposedSwitch for dealing with "unknown" types (i.e. types for whose EPackage no delegate has been registered) should be changed.  I would propose an algorithm as follows: For an instance of the unknown type X get eAllSuperTypes and filter out any unknown types. If we end up with an empty set or a single type we're done. If we end up with multiple types then we continue to eliminate any types which are direct or indirect super types of another type in this set. If we still have more than one type left, we would simply pick the first of these.