Nature of Parametrized types

Waldemar Horwat waldemar at google.com
Fri Mar 21 15:41:39 PDT 2008


Doing this would require multiple inheritance if you tried to apply it to a two-level class hierarchy.

class A.<X>;
class B.<X> extends A.<X>;

Now consider where the unqualified type B would belong in the hierarchy.

    Waldemar


Peter Hall wrote:
>>  Note that this is not to say that the type "Cls" is nonsensical on its
>>  own. Some operations are possible with it: it can be compared to other
>>  types, it can be captured as a value and passed around, and it can be
>>  instantiated with argument types. You just can't "reach into" it before
>>  it's been parameterized, any more than you can "reach into" an
>>  un-applied function.
>>
> 
> Ok. Does "Cls.<int> is Cls" evaluate to true? ie, could the
> specification be written so that:
> 
>      class Cls.<T1,T2> extends S {  /* code using T1 and T2 */ }
> 
> is compiled as if you had written:
> 
>      class Cls extends S {   }
> 
> but somehow internally marked with the parameters that are required in
> order to instantiate it.
> 
> And, on encountering references to Cls.<string,int>, generate an
> unnamed class  as if created by the following ES4 code:
> 
>      class Cls_string_int extends Cls { /* replace T1,T2,.. here */}
> 
> So that:
> 
>     new Cls.<string,int> is Cls;
> 
> evaluates to true.
> 
> Then it could also allow code like this:
> 
>      class MyCls.<S1> extends Cls.<S1,int> {  /* code using S1 */  }
> 
> So, when MyCls.<string> is referenced, it would generate an unnamed
> class as if written:
> 
>      class MyCls_string extends Cls_string_int {  /* .... */  }
> 
> And the "is" relationship holds throughout.
> 
> The only obvious niggle is that the Java behaviour for statics would
> naturally emerge, so you would have to take them into special account
> to get the behaviour you want.



More information about the Es4-discuss mailing list