Extrait du course adding wildcards to the Java programming language

1. INTRODUCTION
Parametric polymorphism is well-known from functional lan-guages such as Standard ML [22], and over the past two Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage, and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC’04, March 14-17, 2004, Nicosia, Cyprus Copyright 2004 ACM 1-58113-812-1/03/04…$5.00 decades similar features have been added to a number of object-oriented languages [21, 28, 13].
For some time it has been clear that the Java programming language was going to be extended with parametric poly-morphism in the form of parameterized classes and poly-morphic methods, i.e., classes and methods with type pa-rameters. A similar mechanism has recently been described for C# [10], and is likely to become part of a future version of that language [18].
2. TYPING WITH WILDCARDS
The motivation behind wildcards is to increase the flexibility of generic types by abstracting over the actual arguments of a parameterized type. Syntactically, a wildcard is an expression of the form ‘?’, possibly annotated with a bound,as in ‘? extends T ’ and ‘? super T ’, where T is a type. In the following we describe the typing of wildcards, and the effect of using bounds.
2.1 Basic Wildcards
Prior to the introduction of generics into the Java programming language, an object of type List was just a list, not a list of any specific type of object. However, often all ele-ments inserted into a list would have a common type, and elements extracted from the list would be viewed under that type by a dynamic cast. To make this usage type safe, GJ lets classes like List be parameterized with an element type.
Objects inserted must then have that type, and in return extracted objects are known to have that type, avoiding the unsafe cast. In most cases, this is an improvement over the previous non-generic scheme, but it makes it harder to treat a list as “just a list”, independent of the element type. For instance, a method could take a List as an argument and only be interested in clearing it or reading properties like the length. In GJ, that could be expressed using a polymor-phic method with a dummy type variable: hTi void aMethod(ListhTi list) { … }
2.2 Bounded Wildcards
Unbounded wildcards solve a class of problems with generic types, but lack one capability of polymorphic methods: if the element type of a list is not completely irrelevant, but required to conform to some bound, this could be expressed in GJ using a type bound (here Number):
hT extends Numberi void aMethod(ListhTi list) { … }
To be able to express that the element type of the list must be a subtype of Number, we again have to introduce a dummy type variable. As before, this only works for meth-ods and not for fields. In order for wildcards to help us out once more, we therefore equip them with bounds to ex-press the range of possible type arguments “covered” by the wildcard: void aMethod(Listh? extends Numberi list) { … }

……..

Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)
Course adding wildcards to the Java programming language (226 KO) (Cours PDF)