The nature of static properties/methods in parameterized classes

Lars Hansen lhansen at adobe.com
Fri Feb 29 03:34:01 PST 2008


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
> 



More information about the Es4-discuss mailing list