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 regards
Mike
> -----Original Message-----
> From: Cormac Flanagan [mailto:[EMAIL PROTECTED]
> Sent: den 13 mars 2008 23:25
> To: Mike Wilson
> Subject: Re: The nature of static properties/methods in
> parameterized classes
>
> On Fri, Feb 29, 2008 at 9:21 AM, Mike Wilson
> <[EMAIL PROTECTED]> wrote:
> > 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#.
>
>
> Mike, I agree with your criticism of Java here for not
> preserving the type
> arguments at runtime, but I think this is an orthogonal design
> issue to the one at hand.
>
> I suspect that the C# model for generics might require algorithms for
> normalizing types, which could introduce additional complexity.
>
> - Cormac
> >
> > 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: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen
> >
> > > Sent: den 29 februari 2008 12:34
> > > To: [email protected]
> >
> >
> > > 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: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED] On Behalf Of
> Lars Hansen
> > > > Sent: 28. februar 2008 18:08
> > > > To: [email protected]
> > > > 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
> > > > [email protected]
> > > > https://mail.mozilla.org/listinfo/es4-discuss
> > > >
> > > _______________________________________________
> > > Es4-discuss mailing list
> > > [email protected]
> > > https://mail.mozilla.org/listinfo/es4-discuss
> > >
> >
> > _______________________________________________
> > Es4-discuss mailing list
> > [email protected]
> > https://mail.mozilla.org/listinfo/es4-discuss
> >
>
>
>
> --
> - Cormac
>
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
