Proposal: Simplified syntax for dealing with parameterized types (correction to ALTERNATIVES section)
james lowden
jl0235 at yahoo.com
Wed Mar 25 06:26:57 PDT 2009
I'm withdrawing this proposal in favor of Jeremy Manson's "Improved Type Inference for Generic Instance Creation", which addresses the repetitive aspects of generic code. I still have type safety concerns over generics, but my proposal didn't address that completely, and I'd rather see it dealt with via full reification in a future release.
-JL-
--- On Tue, 3/24/09, james lowden <jl0235 at yahoo.com> wrote:
> From: james lowden <jl0235 at yahoo.com>
> Subject: Re: Proposal: Simplified syntax for dealing with parameterized types (correction to ALTERNATIVES section)
> To: coin-dev at openjdk.java.net
> Date: Tuesday, March 24, 2009, 9:50 AM
> 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.
More information about the coin-dev
mailing list