delegating to typed objects

Brendan Eich brendan at
Tue Jul 10 08:53:11 PDT 2007

On Jul 10, 2007, at 8:21 AM, Kris Zyp wrote:

> Because it's possible to violate the type constraints on fixtures in
> the non-subclass object created by the function constructor?
> Not if the instance of F is a instance of C.
> 1. Classes do not constrain types, have to check everything...
> Certainly don't want that. However, checking to see if an  
> incompatible method error needs to be thrown on every method call  
> requires extra checks as well doesn't it?

The class methods can't be extracted or called without this binding  
to the object from which they were extracted or in which they were  
found, so there's no type check. From the reference implementation:

 >> class C { public var x : string; public function m(y) { x = y } }
 >> c = new C
[object C]
 >> c.x = 42
 >> function F() {}
 >> F.prototype = c
[object C]
 >> f = new F
[object Object]
 >> f.x
 >> f.m(43)
 >> f.x
 >> c.x

> 2. Delegate creation via (new F) given F.prototype = new C and class
> C must make an instance of C, not of Object. This is not backward
> compatible.
> Why not make (new F) be an instance of C if C is a subclass of  
> Object, otherwise make it an instance of Object?

Every type is a subtype of Object except undefined (the type;  
undefined is the name of the type and its one value), so the  
otherwise to that if would never be taken.

>  That would maintain backwards compatibility wouldn't it?

No -- see SpiderMonkey excerpt from a previous message:

js> function F(){}
js> F.prototype = d = new Date
js> f = new F
js> f.__proto__ === d
js> f.setTime(0)
typein:10: TypeError: Date.prototype.setTime called on incompatible  

> In the former
> case, you should get a type error. In the latter, you can do what you
> say you want, but you have to write the class with extra qualifiers.
> Type errors is what I want. I would want (new F).x = 4 to throw a  
> type error if x is defined as a String in C (or I guess if x is  
> defined as a String, ES4 fixtures cause an implicit type  
> conversion, at least in the ref impl, but type errors would surely  
> be in order at some point).

Wanting a type error instead of a conversion is a separate topic, so  
let's talk about it in another thread. See also

Having long ago proposed separate is/as/to annotations for subtype- 
test-or-null, subtype-or-throw, and conversion, I'm not in favor of  
more than : annotations. And we need converting annotations to self- 
host ES1-3 builtins, the DOM, etc.  But please do start another  
thread if you can suggest something to handle that use case and the  
one you have in mind. First a statement of the use-case you have in  
mind would be helpful.


More information about the Es4-discuss mailing list