Friday, March 30, 2007

TYPES, VALUES AND VARIABLES(7)

TYPES, VALUES AND VARIABLES(7)

This section, §4.5 needs just a little explanation and I’ve found it difficult to come up with an illustration, maybe as we go into later sections, one will spring up.

PARAMETERIZED TYPES:

A parameterized type consists of either one of a class or interface name C and an actual type argument list 1, …, TN>. A compile time error results if C is not a class or interface name.

Vector //class or interface name, Vector. Arguments: accepts Integer.

Seq> //class or interface name, Seq. arguments: a generic class, Seq which

generic class has argument, A.

What this section is saying is that type variables could end up being parameterized types if declared so and that a parameterized type could be bounded by another type which bound is called the supertype. This type and its bound has a binary relation that defines the bound, and it is a proper supertype if the parameterized type is not equal to its bounding type.

On the other hand a type variable could have a supertype but when it is declared as a parameterized type, it’s supertype is the bounding on this parameter within this section of the class or interface and not the supertype when it was declared a type variable.

Type arguments and wildcards:

Type arguments are either:

A. Reference types.

B. Wildcards, which wildcard can be bounded with the words extends or super on a reference type.

Reference types have been dealt with above.

For a wildcard type argument, , if unbounded like below:

void printCollection(Collection c){

for (Object o: c){

System.out.println(o);

}

}

Then we say the wildcard allows any kind of Collection to be used as its parameter.

According to the discussion on §4.5.1 of the jls, assuming Object for a , which is natural, is discouraged in java because:

  1. Object would be advisable to be explicitly stated if it is needed.
  2. assuming acceptability of Object will probably be invalid because Object is rarely used as an argument.
  3. the any parameter type is not enough for Object to be assumed

Features:

a. Wildcards are useful in situations when only partial knowledge about the type parameters is required.

b. wildcards may be given explicit bounds. An upper bound is signified by the syntax:

? extends B //where B is the bound

Using bounds on a wildcard is better than declaring genericity on method, if the type parameter is a method, although both methods could be used.

? super B //where B is the bound

c. 2 type arguments are provably distinct if neither of the arguments is a type variable or wildcard, and the two arguments are not the same type.

Not distinct: boolean addAll(Collection c) not distinct from boolean addAll(Collection c)

Distinct: boolean addAll(Collection c) distinct from, boolean addAll(Collection c)

TYPE ARGUMENT CONTAINMENT AND EQUIVALENCE: We’ll illustrate this using two classes, one NigerianPopulation class and LagosPopulation class. Let’s say NigerianPopulation class is defined by the numeric range i, where 10m ≤ i ≤ 130m and LagosPopulation is defined by the range j, where 3m ≤ j ≤ 5m. let’s assume that LagosPopulation is a subclass of NigerianPopulation,

Then LagosPopulation <: NigerianPopulation //LagosPopulation is a subtype of

NigerianPopulation

Where <= defines a contained in relationship

  1. ? extends LagosPopulation <= ? extends NigerianPopulation is true
  2. ? super LagosPopulation <= ? super NigerianPopulation is true
  3. LagosPopulation <= LagosPopulation
  4. LagosPopulation <= ? extends LagosPopulation
  5. LagosPopulation <= ? super LagosPopulation

Members and constructors of parameterized types:

I’ll use just an example illustrating the notes in the jls:

package generic_example;

public class SecondGeneric {

Boolean makeBelieve = true;

String name;

//this method will be overridden

String getName(){

return name;

}

}

//the type parameters for FirstGeneric are

//String and Integer

public class FirstGeneric

extends SecondGeneric {

String name;

FirstGeneric(String thename){

this.name = thename;

}

//Note that the type of a method in this class

//corresponds to one of the type arguments of

//the class. type inference makes method genericity

//somewhat duplicative. the method's type is bound

//by the arguments that are substituting for each

//type parameter of the class. on extending

//the type of this method must be the same as the

//type of the method whose class is extended.

String getName(){

return name;

}

}

No comments: