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

james lowden jl0235 at yahoo.com
Tue Mar 24 07:50:33 PDT 2009

I see what you're saying. . . there's no way, having made StringList a subinterface of List, 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 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 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; class ArrayStringList = ArrayList; 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.

More information about the coin-dev mailing list