Proposal: Access to Generic Type Parameters at Compile-Time (original) (raw)

Joseph D. Darcy Joe.Darcy at Sun.COM
Sun Mar 22 22:44:20 PDT 2009

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

More information about the coin-dev mailing list