Re: Nature of Parametrized types
On Fri, Mar 21, 2008 at 10:41 PM, Waldemar Horwat <[EMAIL PROTECTED]> wrote: > Doing this would require multiple inheritance if you tried to apply it to a > two-level class hierarchy. > > class A.; > class B. extends A.; > > Now consider where the unqualified type B would belong in the hierarchy. Yes, you are right... you would need B. to extend both A. and B. But that could be solved, in the same spirit as my original suggestion, by treating unqualified B as an empty interface, so as to maintain the "is" relationship. Peter ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Nature of Parametrized types
Doing this would require multiple inheritance if you tried to apply it to a
two-level class hierarchy.
class A.;
class B. extends A.;
Now consider where the unqualified type B would belong in the hierarchy.
Waldemar
Peter Hall wrote:
>> Note that this is not to say that the type "Cls" is nonsensical on its
>> own. Some operations are possible with it: it can be compared to other
>> types, it can be captured as a value and passed around, and it can be
>> instantiated with argument types. You just can't "reach into" it before
>> it's been parameterized, any more than you can "reach into" an
>> un-applied function.
>>
>
> Ok. Does "Cls. is Cls" evaluate to true? ie, could the
> specification be written so that:
>
> class Cls. extends S { /* code using T1 and T2 */ }
>
> is compiled as if you had written:
>
> class Cls extends S { }
>
> but somehow internally marked with the parameters that are required in
> order to instantiate it.
>
> And, on encountering references to Cls., generate an
> unnamed class as if created by the following ES4 code:
>
> class Cls_string_int extends Cls { /* replace T1,T2,.. here */}
>
> So that:
>
> new Cls. is Cls;
>
> evaluates to true.
>
> Then it could also allow code like this:
>
> class MyCls. extends Cls. { /* code using S1 */ }
>
> So, when MyCls. is referenced, it would generate an unnamed
> class as if written:
>
> class MyCls_string extends Cls_string_int { /* */ }
>
> And the "is" relationship holds throughout.
>
> The only obvious niggle is that the Java behaviour for statics would
> naturally emerge, so you would have to take them into special account
> to get the behaviour you want.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Nature of Parametrized types
> Note that this is not to say that the type "Cls" is nonsensical on its
> own. Some operations are possible with it: it can be compared to other
> types, it can be captured as a value and passed around, and it can be
> instantiated with argument types. You just can't "reach into" it before
> it's been parameterized, any more than you can "reach into" an
> un-applied function.
>
Ok. Does "Cls. is Cls" evaluate to true? ie, could the
specification be written so that:
class Cls. extends S { /* code using T1 and T2 */ }
is compiled as if you had written:
class Cls extends S { }
but somehow internally marked with the parameters that are required in
order to instantiate it.
And, on encountering references to Cls., generate an
unnamed class as if created by the following ES4 code:
class Cls_string_int extends Cls { /* replace T1,T2,.. here */}
So that:
new Cls. is Cls;
evaluates to true.
Then it could also allow code like this:
class MyCls. extends Cls. { /* code using S1 */ }
So, when MyCls. is referenced, it would generate an unnamed
class as if written:
class MyCls_string extends Cls_string_int { /* */ }
And the "is" relationship holds throughout.
The only obvious niggle is that the Java behaviour for statics would
naturally emerge, so you would have to take them into special account
to get the behaviour you want.
>
> > 2. Is it legal to extend a general parametrized class, or may you only
> > extend a specific parametrization?
>
> Only a specific parameterization.
See above. But I think this is quite an important thing not to leave
out. Once you have implemented something with parametrized types, it
could be a maintainability nightmare if, further down the line, you
find that you have to add functionality by subclassing.
>
> > 3. It seems that there are use-cases for statics being
> > per-parametrization and also for them being global for all
> > parametrizations.
>
> There are certainly some plausible use cases, but they are (I think)
> beyond the scope of what we're doing this time around. As are quite a
> number of extensions to parametric types we've seen in the wild. If they
> become pressing in the future, future editions may address them.
>
If statics are always per-parametrization, then you can very easily
achieve the same effect as the other option by creating package-level
properties or statics on a separate class. It's not as nice to look
at, but quite acceptable. The other way around would be trickier.
Peter
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Nature of Parametrized types
Peter Hall wrote:
> I have a few questions/comments about parametrized types. Some I know
> has been discussed, but I still unclear on the outcome of those
> conversations.
Good questions!
> 1. If there is a type T., can T be referenced itself, or must it
> be referenced for some specific values of J and K?
>
> That is, can I say:
> T1 = T;
> or must it always be:
> T1 = T.;
> My understanding is that, conceptually, T is not a type by itself but
> that a type is generated each time that a different combination of
> parameters is supplied. Is this understanding correct? If so, it
> pretty much enforces that static properties are not shared between
> each parametrization.
This question is also raised in tickets #247 and #249, as well as some
recent committee discussion. The conclusion I think we've reached is to
immitate C++ and C#, not Java. Or as Lars summarized, given this class:
> class Cls. {
> static var v;
> }
we are going to spec the following:
>
> - Cls.v is nonsensical
> - You have to write Cls..v
> - Cls..v is different from Cls..v
> - The result of
>
> var p = Cls.
> var q = Cls.
> p === q
>
> is always true.
>
In other words, there is no sharing between instantiations on non-equal
type arguments, but all instantiations on equal type arguments should
produce the same (memoized) instantiated type / class, with sharable
static slots on the classes.
At present, I believe the RI is in violation of these rules. But it is
the intended position.
Note that this is not to say that the type "Cls" is nonsensical on its
own. Some operations are possible with it: it can be compared to other
types, it can be captured as a value and passed around, and it can be
instantiated with argument types. You just can't "reach into" it before
it's been parameterized, any more than you can "reach into" an
un-applied function.
> 2. Is it legal to extend a general parametrized class, or may you only
> extend a specific parametrization?
Only a specific parameterization.
> 3. It seems that there are use-cases for statics being
> per-parametrization and also for them being global for all
> parametrizations.
There are certainly some plausible use cases, but they are (I think)
beyond the scope of what we're doing this time around. As are quite a
number of extensions to parametric types we've seen in the wild. If they
become pressing in the future, future editions may address them.
-Graydon
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Nature of Parametrized types
I have a few questions/comments about parametrized types. Some I know
has been discussed, but I still unclear on the outcome of those
conversations.
1. If there is a type T., can T be referenced itself, or must it
be referenced for some specific values of J and K?
That is, can I say:
T1 = T;
or must it always be:
T1 = T.;
My understanding is that, conceptually, T is not a type by itself but
that a type is generated each time that a different combination of
parameters is supplied. Is this understanding correct? If so, it
pretty much enforces that static properties are not shared between
each parametrization.
2. Is it legal to extend a general parametrized class, or may you only
extend a specific parametrization?
ie, is this allowed:
class T. { var x:A; }
class S. extends T { }
?
This seems to have all kinds of problems. For one, there is no
equivalent of "super()" to pass the parameters to the super class.
However, certain uses of parametrized classes might be unfeasible if
you can't extend the class without choosing a parametrization.
3. It seems that there are use-cases for statics being
per-parametrization and also for them being global for all
parametrizations. If I wanted to keep a count of all the instances of
a parametrized class had been created, I'd need a static var to be
global across all parametrizations. But there are probably more use
cases for it to be per-parametrization. So it would actually be really
nice if you could choose between these different scopes. Without
introducing new keywords, using a double "static static" could
indicate that a property is static across all parametrizations, while
a single "static" would indicate that a property was static on a
per-parametrization basis.
e.g:
class A. {
public static static var a:int = 0;
public static var b:int = 0;
}
A..a ++;
A..b ++;
A..a; // 1
A..b; // 0
I suppose an alternative would be a magic always-open namespace.
Peter
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
