Proposal: Access to Generic Type Parameters at Compile-Time

[Joseph D. Darcy]

David Walend wrote:
> I've been hesitating to submit this proposal because I have seen so
> few other people push generics as hard as I do. However, the  
> discussion around method and field literals -- and adding type  
> parameters to Field and Method -- may make it more relevant than I  
> first thought.
>
> My test for reflection APIs is using the API to convert between a  
> class in memory and bytes in a stream. One common corner case is  
> converting  Map<Key,Value>. I often create a simple class for the  
> chore. If Field becomes parameterized, I'll be using  
> Field<Map<Key,Value>> in that class, and will perhaps be creating  
> specialized classes for different Keys and Values. If the Key or Value  
> types take parameters, the generics will be three layers deep.
>
> Type parameters on methods that return types with their own type  
> parameters invites developers to wade into the depths of layered  
> generics. This proposal addresses one of the associated pain points.
>
> I've attempted to write a spec section which I hope is clear. I'm not  
> sure it's wrong.
>
> What do you think?
>
> Dave
>
> David Walend
> david at walend.net
>
> ---
>
> Access to Generic Type Parameters at Compile-Time
>
> AUTHOR: David Walend
>
> OVERVIEW
>
> FEATURE SUMMARY:
>
> This feature allows a developer to gain dot access to the type
> parameters of type parameters in classes and interfaces, similar to
> accessing encapsulated fields in the class, but only in source code.
> For example, given Digraph<Node,Edge>, one could declare  
> Subgraph<ContainerGraph extends Digraph> extends  
> Digraph<ContainerGraph.Node,ContainerGraph.Edge>.
>
> MAJOR ADVANTAGE: This change will simplify the use of layered generics
> and opens the door to richer general purpose code.
>
> MAJOR BENEFIT: This change transfers the rote work of resolving
> specified types from the developer to the compiler. Given the
> mechanical nature of the task, that is where the work belongs.
>
> MAJOR DISADVANTAGE: Generics in Java are already complex; the Java
> Generics FAQ is very large. This change will make it slightly longer,
> and require developers to learn one more (relatively intuitive)
> detail.
>
> ALTERNATIVES:
>
> 1) Do nothing.
>
> 2) Full reification, if done well, would provide similar compile-time
> language-level access beyond the type specifiers. (This option is one
> of the case examples of things too large for project coin.)
>
> 3) Diminish generics' prominent position in Java by removing the
> compile-time warnings.
>
> 4) Remove generics from Java.
>
> EXAMPLES:
>
> My examples are directed graph examples from the JDiraph project on
> java.net. The semiring (advanced) example was inspired by Cormen,  
> Leiserson and Rivest, 26.4. I show what the code looks like in JDK5  
> first, then with the access to generic type parameters proposed.
>
> ---
>
> SIMPLE EXAMPLE: Given interface Digraph<Node,Edge>, define Paths
> through the Digraph, a Digraph representing a probalistic transitions
> in the dialog, and an instance of Path that represents a conversation.
>
> JDK5 Syntax -- three type specifiers, one of which requires the
> developer to match the first two by hand:
>
> interface Path<Node,Edge,ThruGraph extends Digraph<Node,Edge>>
>      extends Digraph<Node,Edge>
>      {
>          Node getHead();
>          ...
>      }
>   

[snip]

When I see a Java type declared to have more than two type parameters my 
initial reaction is usually "this type isn't using the best 
decomposition of the problem space."

-Joe