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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen > Sent: 28. februar 2008 18:08 > To: es4-discuss@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@mozilla.org > https://mail.mozilla.org/listinfo/es4-discuss > _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
