Re: const VS static final class variable ?
On Aug 17, 2007, at 3:37 PM, Brendan Eich wrote:
> On Aug 17, 2007, at 1:10 PM, Garrett Smith wrote:
>
>> what is the difference between x1 and x2?
>>
>> class A {
>>const x1;
>>static final x2;
>
> You need a var before x2. Also you can't add final except before
> classes and methods (the reference implementation currently parses
> 'class A { static final var x; }' but that's a bug).
>
> Are you thinking of Java, or some other language here? If this is
> based on an ES4 example or spec, can you cite the URL?
>
> The obvious difference, ignoring the intended illegality of static
> final var x2, is that x2 is static, so per class, not per instance.
I should add that const is write-once, so you can have a const x1
instance field. A constructor could write three different values to
three different instances' x1 fields. In this case const does not
mean per-class, as static const does, or a hypothetical static final
var might.
/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Are Static Members Inherited?
This has come up on this list before; please see the archive: https://mail.mozilla.org/private/es4-discuss/2007-January/thread.html (the "inheriting statics" thread). Also, what section 9.2.7 do you mean? Could you cite the URL of the document containing that section? Thanks, /be On Aug 17, 2007, at 2:05 PM, Garrett Smith wrote: > The example in section 9.2.7 demonstrates static members, including > those of an ancestor superclass, being accessible through an instance. > > Section 9.6.2 clearly states that static methods are not accessible > through derived class objects (though does not mention anything about > static properties). > > Am I to understand that static members (methods and properties) are > visible through the scope chain of instances of derived classes (as in > example in 9.2.7)? > > 2. Can static methods be abstract? I think that this should be a > compile-time error (static abstract function). > > Garrett > ___ > Es4-discuss mailing list > Es4-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: const VS static final class variable ?
On Aug 17, 2007, at 1:10 PM, Garrett Smith wrote:
> what is the difference between x1 and x2?
>
> class A {
>const x1;
>static final x2;
You need a var before x2. Also you can't add final except before
classes and methods (the reference implementation currently parses
'class A { static final var x; }' but that's a bug).
Are you thinking of Java, or some other language here? If this is
based on an ES4 example or spec, can you cite the URL?
The obvious difference, ignoring the intended illegality of static
final var x2, is that x2 is static, so per class, not per instance.
/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Array and Object Literal Types
On Aug 17, 2007, at 2:47 PM, Garrett Smith wrote: > It would be nice to have Array literal syntax declare it's ArrayType > before the declaration of the array. > > For example: > > 1. var x : Array = [ "foo", "bar", document.title, > getAnotherString() ]; Array is not a parameterized type. If it were, the syntax would be Array.. Array must be backward compatible, so if it were changed to be parameterized by element type, then it would have to default to Array.<*> when used without a parameter list. But we don't have default type parameters, and anyway a type-parametric Array reference without the actual type param list would be ambiguous: should it mean Array.<*> by default, or Array, with instantiation using an actual type param happening later: let A = Array; type TA = A. ? So there's no good way to overload Array as you want. Also, Array is closer to Object than to any homogenous tuple or vector type. Hence the separate http://wiki.ecmascript.org/doku.php?id=proposals:arrays http://wiki.ecmascript.org/doku.php?id=proposals:vector proposals. > 2. var x = [ "foo", "bar", document.title, getAnotherString() ] : > String; > > example 1 is more clear to read because in a long array, you'd see > right away what type of Array it is. Please see the above proposals and the prior proposals: http://wiki.ecmascript.org/doku.php?id=spec:type_system http://wiki.ecmascript.org/doku.php?id=spec:type_relations > Is the former syntax (or some variant thereof) going to be available? No, as explained above. But what you might want is: let x : [string] = ["foo", "bar", document.title, getAnotherString()]; Notes: * let trumps var in any hand ;-) * string is the type of "foo", String is the dynamic class for wrappers, as in ES1-3 that shares its .prototype with string instances as well as String instances, via the usual prototype-based delegation. Prefer string in general. * [string] is a type expression denoted a structural array type. > What about for Objects? See structural object types. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Array and Object Literal Types
It would be nice to have Array literal syntax declare it's ArrayType before the declaration of the array. For example: 1. var x : Array = [ "foo", "bar", document.title, getAnotherString() ]; 2. var x = [ "foo", "bar", document.title, getAnotherString() ] : String; example 1 is more clear to read because in a long array, you'd see right away what type of Array it is. Is the former syntax (or some variant thereof) going to be available? What about for Objects? Garrett ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
9.6.2 - 'this' or 'super' in a static method
9.6.2 It is an error for the 'this' or 'super' expression to appear in the body of a static method. 1. Is this error mentioned a compile-time error? 2. Why does 'this' in a static method generate an error? (it shouldn't refer to the class?) 3. does 'superclass' in a static method refer to the class' superclass? (since 'super' is forbidden). ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Are Static Members Inherited?
The example in section 9.2.7 demonstrates static members, including those of an ancestor superclass, being accessible through an instance. Section 9.6.2 clearly states that static methods are not accessible through derived class objects (though does not mention anything about static properties). Am I to understand that static members (methods and properties) are visible through the scope chain of instances of derived classes (as in example in 9.2.7)? 2. Can static methods be abstract? I think that this should be a compile-time error (static abstract function). Garrett ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
class prototype object vs class instance properties
What is the difference between a class's prototype object and it's
instance properties?
class A {
var x : uint = 10; // instance property.
prototype var x : uint = 20; // another instance property in the
prototype chain.
}
class B extends A { }
My understanding is that the result would be:
new B().x; // result is 20.
What would be the benefit of a class having a prototype over 9instance
properties/methods?
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
const VS static final class variable ?
what is the difference between x1 and x2?
class A {
const x1;
static final x2;
}
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
RE: Self type
Peter,
This was my confusion, as well. I was about to send a reply to Cormac's
email but, in working through my reply, I realized what was going on.
The types are not quite equivalent to substituting T1 and T2, because
Self is the concrete object type which needs to be a subtype of the
defined type but not exactly the same, so the equivalent expressions
are:
type T1 = { f:function(this:t1, z:t1):t1, w:int } for some t1 <: T1
type T2 = { f:function(this:t2, z:t2):t2 } for some t2 <: T2
This means that
var x:T1 = { ... }:T1; var y:T2 = x;
is not an error, because T1 is a legitimate candidate for t2 <: T2.
-- Eylon --
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter Hall
Sent: Friday, August 17, 2007 7:35 AM
To: Cormac Flanagan
Cc: Brendan Eich; es4-discuss
Subject: Re: Self type
I think my confusion here, is perhaps that I'm seeing this a slightly
different way. What you are saying seems to suggest that Self type
annotations can behave differently at runtime. To me, this example from
the wiki should be an error:
type T1 = { f:function(this:Self, z:Self):Self, w:int} var x:T1 = { ...
}:T1 type T2 = { f:function(this:Self, z:Self):Self } var y:T2 = x; //
ERROR
Because the types are equivalent to:
type T1 = { f:function(this:T1, z:T1):T1, w:int} type T2 = {
f:function(this:T2, z:T2):T2}
So T1's f and T2's f are incompatible. In a real situation, an author
would have to be a bit more careful about how the types are defined, and
probably use wildcard types or Object (or perhaps fully expanded type
definitions) where necessary. But I think that is better than having
wildcards inserted automatically behind the scenes.
Peter
On 8/14/07, Cormac Flanagan <[EMAIL PROTECTED]> wrote:
>
>
> Peter Hall wrote:
> > On 8/14/07, Eylon Stroh <[EMAIL PROTECTED]> wrote:
> >> From the proposal:
> >> "The return type T2 is ok, even if the function returns a T1
instead...
> >> covariant occurrences of Self (eg in the result type) are replaced
> >> by T2"
> >>
> >
> > I was also wondering about this.
> > To me, if someone writes "Self" for an argument or return type, they
> > probably mean T1. If they actually want it to be "*", why not let
> > them write "*"? Or is there something else going on here?
>
> Yes, it would be intuitive to replace "Self" by T1, but it would be
> unsound, since Self really means:
>
>the actual allocated type of the current object, which is some
unknown
>subtype of the known static type T1 of that object
>
> so we can only safely replace Self by T1 in "covariant" contexts
> (where we get stuff out, and don't care if we actually get a subtype),
> but not in "contravariant" contexts, such as argument positions.
>
> - Cormac
> ___
> Es4-discuss mailing list
> Es4-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Self type
I think my confusion here, is perhaps that I'm seeing this a slightly
different way. What you are saying seems to suggest that Self type
annotations can behave differently at runtime. To me, this example
from the wiki should be an error:
type T1 = { f:function(this:Self, z:Self):Self, w:int}
var x:T1 = { ... }:T1
type T2 = { f:function(this:Self, z:Self):Self }
var y:T2 = x; // ERROR
Because the types are equivalent to:
type T1 = { f:function(this:T1, z:T1):T1, w:int}
type T2 = { f:function(this:T2, z:T2):T2}
So T1's f and T2's f are incompatible. In a real situation, an author
would have to be a bit more careful about how the types are defined,
and probably use wildcard types or Object (or perhaps fully expanded
type definitions) where necessary. But I think that is better than
having wildcards inserted automatically behind the scenes.
Peter
On 8/14/07, Cormac Flanagan <[EMAIL PROTECTED]> wrote:
>
>
> Peter Hall wrote:
> > On 8/14/07, Eylon Stroh <[EMAIL PROTECTED]> wrote:
> >> From the proposal:
> >> "The return type T2 is ok, even if the function returns a T1 instead...
> >> covariant occurrences of Self (eg in the result type) are replaced by
> >> T2"
> >>
> >
> > I was also wondering about this.
> > To me, if someone writes "Self" for an argument or return type, they
> > probably mean T1. If they actually want it to be "*", why not let them
> > write "*"? Or is there something else going on here?
>
> Yes, it would be intuitive to replace "Self" by T1, but it would be
> unsound, since Self really means:
>
>the actual allocated type of the current object, which is some unknown
>subtype of the known static type T1 of that object
>
> so we can only safely replace Self by T1 in "covariant" contexts (where
> we get stuff out, and don't care if we actually get a subtype),
> but not in "contravariant" contexts, such as argument positions.
>
> - Cormac
> ___
> Es4-discuss mailing list
> Es4-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
