The nature of static properties/methods in parameterized classes

Lars Hansen lhansen at
Thu Feb 28 09:07:32 PST 2008

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


More information about the Es4-discuss mailing list