Yep, I mean exactly that ... technically inconsistent due getters/setters
... e.g.
function C() {
this.willThrow = "whatever";
}
Object.defineProperty(C.prototype, "willThrow", {
set: function () {
throw "doh!";
}
});
so the __proto__ there works as expected unless we don't use defineGetter
directly with the new instance with same "willThrow" property name but if
rather than set there was a value in the descriptor, nothing will happen
and the property is set as configurable,enumerable,writable no matter what
was the inherited __proto__.whatever descriptor.
Also with this mechanism and without proxies __proto__ cannot be used to
create frozen instances directly ( or not extendible or sealed )
Not that I need it, just some thought I had on it.
br
On Tue, Mar 27, 2012 at 1:22 PM, Brendan Eich <[email protected]> wrote:
> Andrea Giammarchi wrote:
>
>> One thing does not scale well in current prototype logic, what has been
>> flagged in the proto is not inherited with same descriptor per each
>> instance ( arguable if expected or not )
>>
>
> You mean when the prototype property is shadowed in the instance by a
> property of the same name created by assignment?
>
> That's true and it goes back to the dawn of time. It's not going to
> change, but as you note, ES5 provides tools other than assignment to create
> properties with non-default attributes.
>
> /be
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
