Approach of new Object methods in ES5

Brendan Eich brendan at mozilla.com
Fri Apr 16 10:28:01 PDT 2010


On Apr 16, 2010, at 1:11 PM, Erik Arvidsson wrote:

> On Fri, Apr 16, 2010 at 09:06, Brendan Eich <brendan at mozilla.com>  
> wrote:
> ... settable __proto__, apart from the object initialiser use case  
> (i.e., on a new object not yet reachable, analogous to ES5's  
> Object.create), is a terrible idea.

[snip]


> Unfortunately there are use case (although limited) that cannot be  
> solved without a mutable __proto__. Extending built *classes* is one  
> such use case.
>
> function HelloElement() {
>   var el = document.createElement('div');
>   el.__proto__ = HelloElement.prototype;
>   el.text = 'Hello';
>   return el;
> }
> HelloElement.prototype = {
>   __proto__: HTMLDivElement.prototype,
>   set text(text) { this.textContent = text; },
>   say: function() {
>     alert('Hello');
>   }
> };
>
> document.body.appendChild(new HelloElement).say();

Does this work cross-browser? Gecko's DOM puts methods and WebIDL  
attributes (getters/setters) on the prototype, which you chain to.  
What happens if you access a standard HTMLDivElement method or getter  
on (new HelloElement)?

Anyway, the Self-ish use case does arise in practice. It is not  
something standard JS has ever catered to. I don't see us  
standardizing mutable __proto__, or even read-only __proto__. We  
should dig into this HelloElement case more before going further with  
mutable __proto__, I think.


> When we have this code sample I'd like to also point out that using  
> __proto__ in an object literal is much more user friendly and more  
> efficient than using Object.create which is design for meta  
> programming and not for users.

Object.create is the standardized form of Crock's beget. It's not bad  
for an API, albeit longer than b-e-g-e-t (but also less likely to  
collide, although collide it did with TIBET's create method on Object).


> Compare the following two:
>
> var obj = Object.create(myPrototype, getOwnProperties({
>   ...
> }));
>
> and:
>
> var obj = {
>   __proto_: myPrototype,
>   ...
> };
>
> It is pretty clear that Object.create was never designed for  
> ordinary, everyday use.

Yes, I allowed for that as cited up top in this message -- __proto__  
in an object initialiser is more usable, and it is useful (modulo  
syntax and stratification lack). Note how the object being initialised  
cannot yet be referenced, so no cycle detection is needed.

To stratify in some sense, or at least avoid name collisions, we would  
need a new name for the property. The names proposal again comes to  
mind: the implementation could create and expose a well-known Name  
instance meaning what __proto__ means now.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100416/17cb4516/attachment.html>


More information about the es-discuss mailing list