Proposal: Simplified syntax for dealing with parameterized types (correction to ALTERNATIVES section)

[james lowden]

I see what you're saying. . . there's no way, having made StringList a subinterface of List<String>, to then have it be an ArrayList (or whatever concrete implementation is desired).  Based on this, and the general triviality of the interface case, I'm thinking that using the syntax for interfaces (or abstract classes) is probably a lot of confusion for minimal/no gain, and am tempted to simply remove it from the proposal.

(Alternately, as you mentioned, we could use it as an alias, but then we have an identifier such as "StringList" floating around the code which isn't *actually* a class or interface or anything after compilation, which results in different reflective behaviors for the class and interface case, which could be messy.)


-JL

--- On Mon, 3/23/09, Howard Lovatt <howard.lovatt at iee.org> wrote:

> From: Howard Lovatt <howard.lovatt at iee.org>
> Subject: Proposal: Simplified syntax for dealing with parameterized types  (correction to ALTERNATIVES section)
> To: coin-dev at openjdk.java.net
> Date: Monday, March 23, 2009, 5:33 PM
> Hi,
> 
> There is a lot to like with proposal since class StringList
> =
> ArrayList<String> would both shorten declarations and
> would partially
> reify the generic class. However there is a problem touched
> on in the
> proposal namely class MyStringList = List<String>
> then StringList sl =
> ...; MyStringList msl ...; sl = msl; // Error. This problem
> is worse
> than suggested in the proposal, consider alternate
> implementations of
> the same interface:
> 
> class StringList = List<String>;
> class ArrayStringList = ArrayList<String>;
> 
> StringList sl = new ArrayList(); // Error
> 
> I think to make this workable you need to either:
> 
> 1. change the mechanism so that the interface and abstract
> class
> version is simply a shorthand and does not create a new
> class or type
> (i.e. simply a type alias), or
> 
> 2. alternatively just drop the interface/abstract class bit
> altogether
> and say the new mechanism can only be applied to
> non-abstract classes.
> 
> 
>   -- Howard.