Description Tom Hofmann 2005-02-15 12:06:36 EST

I20050215

See also bug 85281 and bug 83600. 

Bug 83600 was fixed by allowing multiple level wildcards to exist in signatures.
This may make sense inside jdt-core, however in the UI those make never sense.
As outlined in bug 85281, multi-level wildcards can be flattened. 

When using content assist, neither multi-level wildcards nor first-level
wildcards make sense. To the user and to in order to select possible parameters
/ right hand sides of assignments, only the flattened types matter.

In my opinion it would make sense that core would provide the flattening of type
signatures. I would suggest that CompletionProposals already contain flattened
type signatures, but if this is not feasible (why), I can also use a utility
method. This utility method could be in Signature.java or in its own class.

This is not something that can be computed lazily on demand, since we already
need the flattened types to display proposals -> we do need the flattened types
for all proposals.

Currently I do flattening in SignatureUtil.getUpper/LowerBound, but this cannot
handle multi-level wildcards.

---- Flattenings:

On the left hand side (e.g. parameter types)
- a first-level lower bound -T becomes the type itself (T)
- a first-level upper bound +T becomes the null type (no lower bound)

On the right hand side (e.g. a method return value)
- a first-level lower bound -T becomes java.lang.Object
- a first-level upper bound +T becomes T

Wildcard bounds (*) behave like the upper bounds on the LHS, like lower bounds
on the RHS.

On either side
- a nested multi-level wildcard List<++T> becomes the null type
- a nested multi-level wildcard List<+-T> becomes List<+T>
- a nested multi-level wildcard List<-+T> becomes List<*>
- a nested multi-level wildcard List<--T> becomes List<-T>