[s243a]

Java Generics: Why do I need this Cast?

In the statement:

VectorAtDevice data1 = chart.devices;

eclipse tells me:

cannot convert from EnumVector<DeviceTypes,Device<?>> to VectorAtDevice

VectorAtDevice is defined by:

public interface VectorAtDevice
              extends VectorAt<DeviceTypes,
                                    Device<?>>{

}

And the first part of the class definition for EnumVector is:

public class EnumVector<K extends Enum<K>,T extends GetType<K>> 
            extends EnumCollection<K,Integer,Vector2<T>,T>
            implements AddElement<T>,
            VectorAt<K,T>{

So EnumVector implements VectorAt<K,T> therefore shouldn't EnumVector<DeviceTypes,Device<?>> implement VectorAt<DeviceTypes,Device<?>> which is also implemented by the interface VectorAtDevice. Therefore I fail to see why the cast is necessary.

Also if if I directly use VectorAt<DeviceTypes,Device<?>> instead of VectorAtDevice I don't need the cast but this seems messy.

This post has been edited by s243a: 12 September 2010 - 03:39 AM

[tectonic.software]

s243a, on 12 September 2010 - 02:37 AM, said:

Java Generics: Why do I need this Cast?

In the statement:

VectorAtDevice data1 = chart.devices;

eclipse tells me:

cannot convert from EnumVector<DeviceTypes,Device<?>> to VectorAtDevice

VectorAtDevice is defined by:

public interface VectorAtDevice
              extends VectorAt<DeviceTypes,
                                    Device<?>>{

}

And the first part of the class definition for EnumVector is:

public class EnumVector<K extends Enum<K>,T extends GetType<K>> 
            extends EnumCollection<K,Integer,Vector2<T>,T>
            implements AddElement<T>,
            VectorAt<K,T>{

So EnumVector implements VectorAt<K,T> therefore shouldn't EnumVector<DeviceTypes,Device<?>> implement VectorAt<DeviceTypes,Device<?>> which is also implemented by the interface VectorAtDevice. Therefore I fail to see why the cast is necessary.

Also if if I directly use VectorAt<DeviceTypes,Device<?>> instead of VectorAtDevice I don't need the cast but this seems messy.

Since VectorAtDevice is a SuperClass of VectorAt, the program would require what extra data VectorAtDevice needs. A cast is not an option at this point. You will have to get your EnumValue and make a new VectorAtDevice with it. If you struggle understanding my post I think someone else on the forums may care to elaborate in a better fashion?

[macosxnerd101]

Not all VectorAt classes are also VectorAtDevice classes. That is why you need the down-cast. Think back to Venn-Diagrams from high school geometry. The subclass is a circle within the superclass circle. Certainly there is space in the superclass circle that isn't the subclass circle.

[s243a]

tectonic.software, on 12 September 2010 - 07:43 AM, said:

Since VectorAtDevice is a SuperClass of VectorAt, the program would require what extra data VectorAtDevice needs.

But why should VectorAtDevice need any extra data? It is just an interface.

Quote

A cast is not an option at this point.

You're right the case gave me a class case exception error. Is their any way to force the cast since all the methods should be the same?

Quote

You will have to get your EnumValue and make a new VectorAtDevice with it.

I think this is the approach I will have to take. I could create a wrapper class for EnumVector which basically is a super-classes EnumVector and declares it implements VectorAtDevice. This seems like an unfortunate workaround with the limitations of java generics. It really dissapoints me because I hoped that Java Gerics would be more powerful.

What I was trying to do is use VectorAtDevice as a type synom. The language Haskell has this feature. It is also suggested in the following paper:\

Quote

Class Synonyms. In a generic language, it can be beneficial to have a class
declaration method that is alternative to subclassing (Palsberg and Schwartzbach,
1994). Such an alternative class declaration method introduces a synonym of a class,
rather than a true subclass, and the synonym can be used where the original class is
expected. The original class and its synonym share the same super and subclasses.
If the generic Java 5 had this type of mechanism, Matrix<E> could have been
declared as a synonym of Ring<ArrayOfArray<Ring<E>>>, as shown below.

class Matrix<E> is Ring<ArrayOfArray<Ring<E>>> { // synonym declaration
Matrix<E> add(Matrix<E> other) {… } // synonym as parameter type
…}

The above example shows how synonyms would have simplified generic definitions
and would have made them more readable.
Synonym declarations should be used when subclassing is not actually needed.
As a matter of fact, type parameters in the generic Java 5 are effectively synonyms
of actual classes, typically class Object. Other languages, such as C++ and Standard
ML support synonyms, which reduces the verbosity of generic code (Garcia et al.,
2003). Unfortunately, synonyms are not universally supported in Java. Introducing
synonym declarations in the generic Java 5 would have reduced the complexity of
the otherwise bulky type expressions.

http://www1.chapman....va-generics.pdf

Before finding the above paper I looked for ways I might be able to declare a synonym. For instance I tried changing extends to implements in my interface declaration. Java doesn't allow this. I checked to see if it might have a key word like Type it doesn't and for kicks I even tried to see if it might have the keyword is as is suggested above.

To me this is unfortunate because showing too much generic information (rather then using type synonyms