Summary: | [1.5][dom] provide API to ask for super/subtypes | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Adam Kiezun <akiezun> |
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> |
Status: | RESOLVED DUPLICATE | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | dirk_baeumer, markus.kell.r |
Version: | 3.0 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: |
Description
Adam Kiezun
2004-06-30 11:08:11 EDT
List<? extends Integer> is NOT a subtype of List<? extends Number> and List<? super Integer> is NOT a supertype of List<? super Number> The old fashion type hierarchies are good enough to resolve type declaration hierarchies. The only refinements would occur when using parameterized supertypes, where in theory, AbstractList<Object> should not be mistaken as a supertype of List<String>. "List<? extends Integer> is NOT a subtype of List<? extends Number>" Strange, last time i saw the spec it was. (it's also that way in the Torgersen paper). you can assign only one way and every instance of List<? extends Integer> is also a List<? extends Number> so i think the former is a subtype of the latter. Can you clarify what you meant when you said it was not? The api request is for a situation like this: i have 2 bindings in hand, i need to check if one is a subtype of the other. Currently i have to walk all superbindings myself but thay does not cover cases like arrays being subtypes of Cloneable or interfaces being subtypes of Object - i have (and other people too) workarounds for these. But the typechecker must be using some information of that sort as well. Exposing it would save a lot of effort on the client side. Also, because there are infinitely many supertypes of something like "List<? super Vector>", the naive walking up the supertype hierarchy is not enough. But again, the typechecker must have that logic already. This request is for exposing that logic via API. Sorry I misread your request. I considered subtype to mean subclass/subinterface. Type compatibility rules are indeed far from trivial, and we could expose some functionality to surface TypeBinding.isCompatibleWith(TypeBinding) from our internals. +1 for a central authority for subtype relationship queries. |