On Apr 16, 2010, at 1:11 PM, Erik Arvidsson wrote:
On Fri, Apr 16, 2010 at 09:06, Brendan Eich <[email protected]>
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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
