Self type

Brendan Eich brendan at
Mon Aug 13 10:06:50 PDT 2007

On Aug 13, 2007, at 5:32 AM, Peter Hall wrote:

> I was just reading the Self type proposal for the first time
> (

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  

> 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,


More information about the Es4-discuss mailing list