Discuss
  • The nature of static properties/methods in parameterized classes

The nature of static properties/methods in parameterized classes

# Lars Hansen (18 years ago)

On 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 Hansen (18 years ago)

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.

# Mike Wilson (18 years ago)

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 Mike Wilson

# Mike Wilson (18 years ago)

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 Mike