The nature of static properties/methods in parameterized classes

Mike Wilson mikewse at hotmail.com
Fri Mar 14 15:30:33 PDT 2008


Thanks Cormac for clarifying and sorry about the noise. I got
hooked on the subject for statics as one of my "favourite" 
(negate that) Java limitations is not being able to do:
  class C<T> {
    static T myT; // error
But I am always impressed by the high level of thinking here
at es4discuss so I feel confident this will be sorted out in a
good way.

Best regards
Mike

> -----Original Message-----
> From: Cormac Flanagan [mailto:cormacflanagan at gmail.com] 
> Sent: den 13 mars 2008 23:25
> To: Mike Wilson
> Subject: Re: The nature of static properties/methods in 
> parameterized classes
> 
> On Fri, Feb 29, 2008 at 9:21 AM, Mike Wilson 
> <mikewse at hotmail.com> wrote:
> > The generics implementation in Java (formerly GJ, Generic Java)
> >  is considered badly broken by many Java programmers, and most
> >  of its deficiencies are caused by the lack of a data structure
> >  representing the instantiated parameterized class.
> >  IMO, this is done the "right" way in C#.
> 
> 
> Mike, I agree with your criticism of Java here for not 
> preserving the type
> arguments at runtime, but I think this is an orthogonal design
> issue to the one at hand.
> 
> I suspect that the C# model for generics might require algorithms for
> normalizing types, which could introduce additional complexity.
> 
> - Cormac
> >
> >  So, if this question is about whether to have any run-time
> >  structure representing instantiated parameterized classes, then
> >  I would strongly advise to take warning of the sad story of
> >  Java's generics before going that route.
> >  (And please excuse the noise if this is not what this question
> >  is about.)
> >
> >  Best regards
> >  Mike Wilson
> >
> >
> >  > -----Original Message-----
> >  > From: es4-discuss-bounces at mozilla.org
> >  > [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Lars Hansen
> >
> > > Sent: den 29 februari 2008 12:34
> >  > To: es4-discuss at mozilla.org
> >
> >
> > > Subject: RE: The nature of static properties/methods in
> >  > parameterized classes
> >  >
> >  > Another strike against the Java way -- maybe only a minor
> >  > point -- is that one has to access statics on the
> >  > uninstantiated type Cls but one can only create new objects
> >  > from the instantiated type Cls.<T>, hence one has to pass
> >  > both objects around, not just one object, if parameterizing
> >  > the program over types in the ES3 way.
> >  >
> >  > --lars
> >  >
> >  > > -----Original Message-----
> >  > > From: es4-discuss-bounces at mozilla.org
> >  > > [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of 
> Lars Hansen
> >  > > Sent: 28. februar 2008 18:08
> >  > > To: es4-discuss at mozilla.org
> >  > > Subject: The nature of static properties/methods in
> >  > > parameterized classes
> >  > >
> >  > > On http://bugs.ecmascript.org/ this is tickets #247, #289.
> >  > > There are links there to background material.
> >  > >
> >  > > We've failed to resolve this properly in the trac, but I need
> >  > > for us to settle this soon (bits of the library depend on the
> >  > > resolution), so I'm going to try email.
> >  > >
> >  > > The issue concerns parameterized classes.  Consider this class:
> >  > >
> >  > >   class Cls.<T> {
> >  > >       static var v;
> >  > >   }
> >  > >
> >  > > Should ES4 follow C++ and C# and say that:
> >  > >
> >  > >   - Cls.v is nonsensical
> >  > >   - You have to write Cls.<int>.v
> >  > >   - Cls.<int>.v is different from Cls.<bool>.v
> >  > >   - The result of
> >  > >
> >  > >       var p = Cls.<T>
> >  > >       var q = Cls.<T>
> >  > >       p === q
> >  > >
> >  > >     is always true.
> >  > >
> >  > > Or should ES4 follow Java and say that:
> >  > >
> >  > >   - Cls.v makes sense
> >  > >   - Cls.<T>.v is just an undefined value
> >  > >   - The result of
> >  > >
> >  > >       var p = Cls.<T>
> >  > >       var q = Cls.<T>
> >  > >       p === q
> >  > >
> >  > >     is implementation-dependent (it's false in the RI).
> >  > >
> >  > > The former model avoids a pigeon-hole problem in that
> >  > > each manufactured type Cls.<T> can behave independently of
> >  > > any other Cls.<Q>, with its own set of statics.  Furthermore,
> >  > > it allows T to be used to annotate static properties and
> >  > > methods of Cls.  It becomes possible for static methods
> >  > > to take into account a type parameter (so meta::invoke
> >  > > on Map and Vector, used to convert from Object or Array,
> >  > > can make use of the value type parameter to construct a
> >  > > properly typed Map).
> >  > >
> >  > > The latter model may have some usability advantages,
> >  > > for example, if v is a constant then Cls.v is that
> >  > > constant regardless of any other context for Cls, and
> >  > > "Map" without type parameters can be called as a function
> >  > > to convert an object to a * -> * Map.
> >  > >
> >  > > Currently ES4 follows Java, this was made explicit at a meeting
> >  > > about a year ago, though the minutes suggest (I wasn't there)
> >  > > that perhaps there was an assumption about that model at the
> >  > > outset.  Anyhow the issue was reopened later because the Java
> >  > > style might be seen to prevent class definitions from 
> containing
> >  > > useful static namespace and type definitions -- that's what
> >  > > those two tickets are about -- because the statics would be
> >  > > properties of the uninstantiated parameterized class, not
> >  > > of a parameterized class, and any static type member could
> >  > > capture an uninstanted type parameter name, which appears to
> >  > > be bad.
> >  > >
> >  > > Since I'm not sure what the arguments for the Java style
> >  > > really are, and I know why the other solution appears
> >  > > to be nice, I tend to dislike what we have now (being of
> >  > > the Java style), and I went so far as to sneak the C#
> >  > > style into the overview paper in the guise of meta-objects.
> >  > > But there might be implementation considerations I don't
> >  > > understand.  Either way, both tickets 247 and 289 remain
> >  > > open, and I think they are on the critical path for
> >  > > the library, so let's try to close them.
> >  > >
> >  > > --lars
> >  > > _______________________________________________
> >  > > Es4-discuss mailing list
> >  > > Es4-discuss at mozilla.org
> >  > > https://mail.mozilla.org/listinfo/es4-discuss
> >  > >
> >  > _______________________________________________
> >  > Es4-discuss mailing list
> >  > Es4-discuss at mozilla.org
> >  > https://mail.mozilla.org/listinfo/es4-discuss
> >  >
> >
> >  _______________________________________________
> >  Es4-discuss mailing list
> >  Es4-discuss at mozilla.org
> >  https://mail.mozilla.org/listinfo/es4-discuss
> >
> 
> 
> 
> -- 
>  - Cormac
> 




More information about the Es4-discuss mailing list