Self type

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Self type

Peter Hall-4
I was just reading the Self type proposal for the first time
(http://wiki.ecmascript.org/doku.php?id=proposals:self_type).

How should a compiler handle this keyword? Should it be able to
substitute a concrete type at compile-time, or must the actual type be
evaluated at runtime (possibly with varying results)?

To give an example of what I am getting at, would the following be an
error (in strict mode)?

type A = {x:Self};
class B extends A {}
var b:B = new B().x; // error: can't implicitly coerce from A to B ??

Or...

function A (){}
A.prototype.f = function():Self{
   return this;
}
function B() {}
B.prototype.f = A.prototype.f;

Is this going to work as intended?

Or can't Self be used outside of the sorts of usage found in the
proposal examples?


Finally, on naming, I don't think it should be upper-case. It's a
keyword, not an actual type. But even "self" , like the lexical
"this", more suggests an instance not a type.

Perhaps "this type" might be clearer, and more akin to the "this
generator" and "this function" that have been proposed elsewhere.


Peter
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Self type

Brendan Eich-2
On Aug 13, 2007, at 5:32 AM, Peter Hall wrote:

> I was just reading the Self type proposal for the first time
> (http://wiki.ecmascript.org/doku.php?id=proposals:self_type).

Cormac should reply authoritatively since he's the author of that  
spec, but I'll have a go.

> How should a compiler handle this keyword? Should it be able to
> substitute a concrete type at compile-time, or must the actual type be
> evaluated at runtime (possibly with varying results)?

Compile-time (see below).

> To give an example of what I am getting at, would the following be an
> error (in strict mode)?
>
> type A = {x:Self};
> class B extends A {}

You can't extend a structural type with a class. Note that the type  
definition just names the structural type, it does not make it a  
nominal type. So its uses can be substituted: class B extends  
{x:Self}, which is not legal.

> var b:B = new B().x; // error: can't implicitly coerce from A to B ??

In any event, the Self identifier is bound within the type expression  
{x: Self} (and we know it's a type expression because in this case  
it's in the right-hand side of a type definition) to the nearest  
enclosing object structural type.

> Or...
>
> function A (){}
> A.prototype.f = function():Self{
>    return this;
> }

Self is bound only within object structural types, so this too is not  
legal.

> function B() {}
> B.prototype.f = A.prototype.f;
>
> Is this going to work as intended?
>
> Or can't Self be used outside of the sorts of usage found in the
> proposal examples?

That's it.

> Finally, on naming, I don't think it should be upper-case. It's a
> keyword, not an actual type. But even "self" , like the lexical
> "this", more suggests an instance not a type.

Hence the straw-man capitalized name.

> Perhaps "this type" might be clearer, and more akin to the "this
> generator" and "this function" that have been proposed elsewhere.

Not bad at a glance. Have to check for ambiguities. Thanks,

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Self type

Peter Hall-4
> > Or can't Self be used outside of the sorts of usage found in the
> > proposal examples?
>
> That's it.
>

In that case, I think it needs to be clearer about how the syntax can
be used. Is it only for use as the "this" parameter for function
types? Seems to me like it should be usable anywhere that the compiler
can reasonably detect the type at compile-time.

e.g.
// this usage is handy for boiler-plate code that you can just copy
// and paste without modification, or from an IDE code snippet template
class A {
var a:Self;
// or...
// var a:this type;
}

type B = {b:Self};



Other places where special treatment of the keyword would be useful is
in interfaces, where the a function argument or return value should be
the same as the type:

interface IClonable {
public function clone():Self;
}
class A implements IClonable {
  public function clone():A { return new A() };
}


That is, users of the interface see the type as being the same as the
interface, but implementors must use their own type here. The example
is identical to clone's return type being IClonable, except that
implementors are required to declare a stronger type.

Peter
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Self type

Brendan Eich-2
On Aug 13, 2007, at 1:59 PM, Peter Hall wrote:

>>> Or can't Self be used outside of the sorts of usage found in the
>>> proposal examples?
>>
>> That's it.
>>
>
> In that case, I think it needs to be clearer about how the syntax can
> be used.

No doubt the proposal needs to be clearer to become a spec.

> Is it only for use as the "this" parameter for function
> types?

No, but it is only for function types within object structural types.  
See the "Use Cases" section:

     * clone, iterators: {f:function():Self}
     * binary methods, equals: { f : function(x:Self):boolean }
     * structural object methods: { f : function(this:Self, ...) } -  
only useful if structural objects with types

at http://wiki.ecmascript.org/doku.php?id=proposals:self_type.

Note that the "same type" case, equals, requires a runtime check to  
be generated. This eliminates the kind of instanceof or downcasting  
hand-written boilerplate seen in Java's equals implementations.

> Seems to me like it should be usable anywhere that the compiler
> can reasonably detect the type at compile-time.
>
> e.g.
> // this usage is handy for boiler-plate code that you can just copy
> // and paste without modification, or from an IDE code snippet  
> template
> class A {
> var a:Self;
> // or...
> // var a:this type;
> }

This is not a strong motivation IMHO.

> type B = {b:Self};

We don't allow recursive structural types in general, but this kind  
of degenerate cycle might be ok. Cormac should comment.

> Other places where special treatment of the keyword would be useful is
> in interfaces, where the a function argument or return value should be
> the same as the type:
>
> interface IClonable {
> public function clone():Self;
> }
> class A implements IClonable {
>   public function clone():A { return new A() };
> }

Indeed -- those are use-cases for interfaces and classes as well as  
for structural types. However, the proposal is focused on structural  
types since unlike classes, |this| binding defaults to the dynamic  
rule from ES1-3, which is weak.

> That is, users of the interface see the type as being the same as the
> interface, but implementors must use their own type here. The example
> is identical to clone's return type being IClonable, except that
> implementors are required to declare a stronger type.

Good point. I'll defer to Cormac on commenting further.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Self type

Eylon Stroh-3
>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"

Please correct me if I'm wrong, but it seems to me that return types can
also be placed in contexts where covariance is not guaranteed.  In the
following (admittedly contrived) code snippet, the type of y.f cannot be
function(this:T2):T2, or even function(this:*):T2 (where * denotes
run-time type checking).  As far as I can tell, it has to be
function(this:*):*.

type T1 = { w:int, f:function(this:Self):Self };
var x:T1 = { w:5, f:function(this:T1):T1
        {
                var result:T1;
                if(this.w < 1)
                {
                        result = { w:1, f:this.f }:T1;
                }
                else
                {
                        result = { w:this.w-1, f:this.f }:T1;
                        // this requires f to return T1
                        result = this.f(result);
                        result.w *= this.w;
                }
                return result;
        }
}:T1;

type T2 = { f:function(this:Self):Self };
var y:T2 = x;

Have I missed something that allows for stronger typing of y.f?

Eylon


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Brendan Eich
Sent: Monday, August 13, 2007 2:40 PM
To: Peter Hall
Cc: es4-discuss; Cormac Flanagan
Subject: Re: Self type

On Aug 13, 2007, at 1:59 PM, Peter Hall wrote:

>>> Or can't Self be used outside of the sorts of usage found in the
>>> proposal examples?
>>
>> That's it.
>>
>
> In that case, I think it needs to be clearer about how the syntax can
> be used.

No doubt the proposal needs to be clearer to become a spec.

> Is it only for use as the "this" parameter for function types?

No, but it is only for function types within object structural types.  
See the "Use Cases" section:

     * clone, iterators: {f:function():Self}
     * binary methods, equals: { f : function(x:Self):boolean }
     * structural object methods: { f : function(this:Self, ...) } -
only useful if structural objects with types

at http://wiki.ecmascript.org/doku.php?id=proposals:self_type.

Note that the "same type" case, equals, requires a runtime check to be
generated. This eliminates the kind of instanceof or downcasting
hand-written boilerplate seen in Java's equals implementations.

> Seems to me like it should be usable anywhere that the compiler can
> reasonably detect the type at compile-time.
>
> e.g.
> // this usage is handy for boiler-plate code that you can just copy //

> and paste without modification, or from an IDE code snippet template
> class A { var a:Self; // or...
> // var a:this type;
> }

This is not a strong motivation IMHO.

> type B = {b:Self};

We don't allow recursive structural types in general, but this kind of
degenerate cycle might be ok. Cormac should comment.

> Other places where special treatment of the keyword would be useful is

> in interfaces, where the a function argument or return value should be

> the same as the type:
>
> interface IClonable {
> public function clone():Self;
> }
> class A implements IClonable {
>   public function clone():A { return new A() }; }

Indeed -- those are use-cases for interfaces and classes as well as for
structural types. However, the proposal is focused on structural types
since unlike classes, |this| binding defaults to the dynamic rule from
ES1-3, which is weak.

> That is, users of the interface see the type as being the same as the
> interface, but implementors must use their own type here. The example
> is identical to clone's return type being IClonable, except that
> implementors are required to declare a stronger type.

Good point. I'll defer to Cormac on commenting further.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Self type

Peter Hall-4
On 8/14/07, Eylon Stroh <[hidden email]> 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?

Peter
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Self type

Cormac Flanagan
In reply to this post by Peter Hall-4


Peter Hall wrote:
>>> Or can't Self be used outside of the sorts of usage found in the
>>> proposal examples?
>> That's it.
> In that case, I think it needs to be clearer about how the syntax can
> be used. Is it only for use as the "this" parameter for function
> types? Seems to me like it should be usable anywhere that the compiler
> can reasonably detect the type at compile-time.
Yes, we plan to support Self in all reasonable places inside classes,
interfaces, structural object types, and structural object expressions.

>
> e.g.
> // this usage is handy for boiler-plate code that you can just copy
> // and paste without modification, or from an IDE code snippet template
> class A {
> var a:Self;
> // or...
> // var a:this type;
> }
>
> type B = {b:Self};

Yes, I think this should be fine.

- Cormac
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Self type

Cormac Flanagan
In reply to this post by Eylon Stroh-3


Eylon Stroh 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"
>
> Please correct me if I'm wrong, but it seems to me that return types can
> also be placed in contexts where covariance is not guaranteed.  In the
> following (admittedly contrived) code snippet, the type of y.f cannot be
> function(this:T2):T2, or even function(this:*):T2 (where * denotes
> run-time type checking).  As far as I can tell, it has to be
> function(this:*):*.
>
> type T1 = { w:int, f:function(this:Self):Self };
> var x:T1 = { w:5, f:function(this:T1):T1
> {
> var result:T1;
> if(this.w < 1)
> {
> result = { w:1, f:this.f }:T1;
> }
> else
> {
> result = { w:this.w-1, f:this.f }:T1;
> // this requires f to return T1
> result = this.f(result);
> result.w *= this.w;
> }
> return result;
> }
> }:T1;
>
> type T2 = { f:function(this:Self):Self };
> var y:T2 = x;
>
> Have I missed something that allows for stronger typing of y.f?

As far as I can see, we can give y.f the type

   function(this:*):T2

since T1 is a subtype of T2.

- Cormac
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Self type

Cormac Flanagan
In reply to this post by Peter Hall-4


Peter Hall wrote:

> On 8/14/07, Eylon Stroh <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Self type

liorean
In reply to this post by Cormac Flanagan
> Peter Hall wrote:
> > type B = {b:Self};

On 14/08/07, Cormac Flanagan <[hidden email]> wrote:
> Yes, I think this should be fine.

I'm all for allowing recursive structural types e.g. for use as binary
trees or linked lists.

    type BinTree = {sin:Self, dx:Self, value:*};
--
David "liorean" Andersson
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Self type

Brendan Eich-2
On Aug 14, 2007, at 10:10 AM, liorean wrote:

>> Peter Hall wrote:
>>> type B = {b:Self};
>
> On 14/08/07, Cormac Flanagan <[hidden email]> wrote:
>> Yes, I think this should be fine.
>
> I'm all for allowing recursive structural types e.g. for use as binary
> trees or linked lists.
>
>     type BinTree = {sin:Self, dx:Self, value:*};

We've decided *not* to specify recursive structural types in general.  
The subtype relation is O(exp(n)) for the simpler algorithm [1], and O
(n^2) for a fairly complex successor algorithm [1]. In the interest  
of simplicity and to minimize costs to small-device implementations,  
we are leaving out recursive structural types of ES4. They could be  
added later; for now, if you need trees and the like, use nominal types.

Dave Herman's analysis is on the wiki, but for some reason I'm  
getting an error trying to access the relevant page [3].

Self-references may be good enough for common "recursive" cases  
(iterator::get, clone, equals, etc.).

/be

[1] http://research.microsoft.com/Users/luca/Papers/SRT.pdf
[2] http://www.cs.ucla.edu/~palsberg/paper/mscs95-kps.pdf
[3] https://wiki.ecmascript.org/ECMA/wiki/doku.php?
id=discussion:classes_as_structural_types_with_branding

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Self type

Nicolas Cannasse
Brendan Eich a écrit :

> On Aug 14, 2007, at 10:10 AM, liorean wrote:
>
>>> Peter Hall wrote:
>>>> type B = {b:Self};
>> On 14/08/07, Cormac Flanagan <[hidden email]> wrote:
>>> Yes, I think this should be fine.
>> I'm all for allowing recursive structural types e.g. for use as binary
>> trees or linked lists.
>>
>>     type BinTree = {sin:Self, dx:Self, value:*};
>
> We've decided *not* to specify recursive structural types in general.  
> The subtype relation is O(exp(n)) for the simpler algorithm [1], and O
> (n^2) for a fairly complex successor algorithm [1]. In the interest  
> of simplicity and to minimize costs to small-device implementations,  
> we are leaving out recursive structural types of ES4. They could be  
> added later; for now, if you need trees and the like, use nominal types.

That's too bad.

Have you not considered having a two-level type spec ? One for
compile-time and one for runtime ? If I'm not wrong, Java did that with
generics.

But anyway, haXe allows :

typedef BinTree<T> = {
    var value : T;
    var left : BinTree<T>;
    var right : BinTree<T>;
}

Which can be generated as the former (less typed) BinTree definition
while still getting proper compile-time typechecking.

The only problem so far is that it seems there is no structural types
support in AVM2/Tamarin yet, or did I miss it ?

Best,
Nicolas

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Self type

Jeff Dyer



On 8/14/07 12:46 PM, Nicolas Cannasse wrote:

> The only problem so far is that it seems there is no structural types
> support in AVM2/Tamarin yet, or did I miss it ?

Nope, no support for structural types in AVM2.

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Self type

Brendan Eich-2
In reply to this post by Nicolas Cannasse
On Aug 14, 2007, at 12:46 PM, Nicolas Cannasse wrote:

> Have you not considered having a two-level type spec ? One for
> compile-time and one for runtime ? If I'm not wrong, Java did that  
> with
> generics.

We do not want a profiled or segmented specification, apart from the  
optional strict mode; we do not want erasure. Since strict mode is  
optional (browsers and small-device implementations will leave it  
out), runtime semantics cannot depend on it.

> The only problem so far is that it seems there is no structural types
> support in AVM2/Tamarin yet, or did I miss it ?

No, it's on the to-do list.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

array slice syntax

Stefan Gössner
Hello,
here are my first questions after following the list quite a while.

1. I really like the array slice syntax [start:end:step] described in
http://developer.mozilla.org/es4/proposals/slice_syntax.html

The description seems to miss the case, where 'start' is greater than 'end'.

a[5:2]

Will
(a) 'step' be implicitely set to -1 ?
(b) an empty array come as result ?
(c) an error occur ?

2. The descendant operator '..' is mentioned only in the tutorial
introduction.
http://developer.mozilla.org/es4/spec/chapter_1_tutorial_introduction.html
I could not find it mentioned elsewhere.

Is it also considered to work with array notation as in:

y..[0]   // access the first element of all arrays of 'y' and it's
descendants.

--
Stefan








_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: array slice syntax

Lars T Hansen-2
On 8/16/07, Stefan Gössner <[hidden email]> wrote:

> Hello,
> here are my first questions after following the list quite a while.
>
> 1. I really like the array slice syntax [start:end:step] described in
> http://developer.mozilla.org/es4/proposals/slice_syntax.html
>
> The description seems to miss the case, where 'start' is greater than 'end'.
>
> a[5:2]
>
> Will
> (a) 'step' be implicitely set to -1 ?
> (b) an empty array come as result ?
> (c) an error occur ?

The description seems to be clear here, the result should be an empty array.

> 2. The descendant operator '..' is mentioned only in the tutorial
> introduction.
> http://developer.mozilla.org/es4/spec/chapter_1_tutorial_introduction.html
> I could not find it mentioned elsewhere.
>
> Is it also considered to work with array notation as in:
>
> y..[0]   // access the first element of all arrays of 'y' and it's
> descendants.

I don't think so.  The descendant operator is for E4X (ECMAScript for
XML, ECMA-357) and has not been discussed in other contexts.  E4X is
not included in ECMAScript 4 at this stage.

--lars
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: array slice syntax

Brendan Eich-2
On Aug 16, 2007, at 10:42 AM, Lars T Hansen wrote:

> On 8/16/07, Stefan Gössner <[hidden email]> wrote:
>> Hello,
>> here are my first questions after following the list quite a while.
>>
>> 1. I really like the array slice syntax [start:end:step] described in
>> http://developer.mozilla.org/es4/proposals/slice_syntax.html
>>
>> The description seems to miss the case, where 'start' is greater  
>> than 'end'.
>>
>> a[5:2]
>>
>> Will
>> (a) 'step' be implicitely set to -1 ?
>> (b) an empty array come as result ?
>> (c) an error occur ?
>
> The description seems to be clear here, the result should be an  
> empty array.

Same as for Python:

 >>> s = [1,2,3]
 >>> s[2:1]
[]

>
>> 2. The descendant operator '..' is mentioned only in the tutorial
>> introduction.
>> http://developer.mozilla.org/es4/spec/ 
>> chapter_1_tutorial_introduction.html
>> I could not find it mentioned elsewhere.
>>
>> Is it also considered to work with array notation as in:
>>
>> y..[0]   // access the first element of all arrays of 'y' and it's
>> descendants.
>
> I don't think so.  The descendant operator is for E4X (ECMAScript for
> XML, ECMA-357) and has not been discussed in other contexts.  E4X is
> not included in ECMAScript 4 at this stage.

We are reserving E4X syntax but not requiring it to be supported.

The .. operator bugs me because it implicitly quotes its right  
operand (as . does), so you could not use it as Perl and other  
languages do for range operator. If it were a dyadic operator that  
did not quote either operand, than it could be overridden by the  
operators proposal (or an operators proposal, at any rate ;-) and  
made to work for range (integer literal or value on left) as well as  
for E4X (XML on left).

Generalizing query, matching, and filtering from E4X to the whole  
language, cleaning up the "un-JavaScript-y" aspects of E4X, making  
use of practical research such as JMatch [1], all will have to wait  
for a future Edition. But we certainly can discuss ideas here. Please  
feel free to do so.

/be

[1] http://www.cs.cornell.edu/Projects/jmatch/
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Self type

Dave Herman-2
In reply to this post by Brendan Eich-2
> Dave Herman's analysis is on the wiki, but for some reason I'm  
> getting an error trying to access the relevant page [3].
>
> ...
>
> [3] https://wiki.ecmascript.org/ECMA/wiki/doku.php?
> id=discussion:classes_as_structural_types_with_branding

You've got the URL wrong here; it should be:

http://wiki.ecmascript.org/doku.php?id=discussion:classes_as_structural_types_with_branding

Is there a broken link somewhere?

Dave
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Self type

Brendan Eich-2
On Aug 16, 2007, at 11:42 AM, Dave Herman wrote:

>> Dave Herman's analysis is on the wiki, but for some reason I'm
>> getting an error trying to access the relevant page [3].
>>
>> ...
>>
>> [3] https://wiki.ecmascript.org/ECMA/wiki/doku.php?
>> id=discussion:classes_as_structural_types_with_branding
>
> You've got the URL wrong here; it should be:
>
> http://wiki.ecmascript.org/doku.php?
> id=discussion:classes_as_structural_types_with_branding

Whoops, you're right -- mistranscription of the internal dokuwiki URL  
to the new ecmascript.org one, sorry.

> Is there a broken link somewhere?

No, but I'm getting permission denied now.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Self type

Dave Herman-2
>> Is there a broken link somewhere?
>
> No, but I'm getting permission denied now.

You need to be logged in for the discussion: namespace.

Dave
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
12