delegating to typed objects

Brendan Eich brendan at mozilla.org
Mon Jul 9 13:17:26 PDT 2007


On Jul 9, 2007, at 12:10 PM, Jeff Dyer wrote:

>>> class C { var x : String; }
>>> c = new C;
>>> function F() {}
>>> F.prototype=c;
>>> f = new F; // f.__proto__ = c
>>> f.x =4;
>>>
>>> If you do this c.x now equals "4", that is the value is not set  
>>> in f, but it goes up the prototype chain and sets 4 into x (and  
>>> does implicit conversion).
>>>
> This behavior is incorrect. For compatibility with ES3, property  
> writes must be shallow.

Agreed, but the question is: how? If you say that f.hasOwnProperty 
('x'), then what is the type constraint on that property's value? If  
it is String, then how is it implemented given that new F creates an  
Object instance, not a C instance?

One could imagine a fixture being added to each Object instance  
created by new F. It would make the type of f be {x:String}, which is  
compatible with C assuming you put 'public' in front of 'var  
x' (that's necessary, otherwise the x in c is in C's internal  
namespace -- please correct me if I have this wrong).

What's not allowed is an unconstrained slot on f -- that would break  
type safety for methods of C that count on x being a String. What  
also seems hard to believe in is some magic getter/setter pair in c  
(f.__proto__) that lets x be stored in each instance (f) but enforces  
the type constraint.

So when you wrote "This behavior is incorrect", did you have in mind  
a fixture per instance, created on demand when assigning ("writes  
must be shallow") to x where f.__proto__.x is a fixture defined by C?  
I.e., a copy-on-write fixture due to the class of f differing (and  
lacking any public::x of its own) from the class of c?

>> If you want x to be a delegated and override-able "plain old"  
>> property, not a fixture, declare C thus:
>>
>> class C { prototype var x : String; }
>>
> To be clear, in the example above this would put a expando property  
> ‘x’ on ‘f.__proto__.__proto__’.

Yes, but it could be shadowed in f instances, inheriting the type  
constraint.

> See my comment before my last one. Making prototypes more like  
> classes would make them less flexible, more complicated, and  
> duplicate functionality that is already available. I don’t see the  
> point, but maybe I’m missing the use case.
>

Using functions as extra constructors may be a use-case, but the  
primary problem is definitional: given functions and classes, what  
*should* happen in Kris's example, and how should it be specified/ 
reference-implemented? Copy-on-write fixtures are a new thing under  
our Sun, it seems to me.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20070709/96c7ea2c/attachment-0002.html 


More information about the Es4-discuss mailing list