The nature of static properties/methods in parameterized classes

Mike Wilson mikewse at hotmail.com
Fri Feb 29 08:21:44 PST 2008


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

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
> 




More information about the Es4-discuss mailing list