Nature of Parametrized types

Peter Hall peter.hall at memorphic.com
Mon Mar 17 13:09:47 PDT 2008


>  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.


>
>  > 2. Is it legal to extend a general parametrized class, or may you only
>  > extend a specific parametrization?
>
>  Only a specific parameterization.

See above. But I think this is quite an important thing not to leave
out. Once you have implemented something with parametrized types, it
could be a maintainability nightmare if, further down the line, you
find that you have to add functionality by subclassing.


>
>  > 3. It seems that there are use-cases for statics being
>  > per-parametrization and also for them being global for all
>  > parametrizations.
>
>  There are certainly some plausible use cases, but they are (I think)
>  beyond the scope of what we're doing this time around. As are quite a
>  number of extensions to parametric types we've seen in the wild. If they
>  become pressing in the future, future editions may address them.
>

If statics are always per-parametrization, then you can very easily
achieve the same effect as the other option by creating package-level
properties or statics on a separate class. It's not as nice to look
at, but quite acceptable. The other way around would be trickier.


Peter



More information about the Es4-discuss mailing list