I'm only just now reading this thread. But I want to add a couple of comments about __proto__. I've been doing a lot of messing around with inheritance patterns in js. I've come to feel that using __proto__ is useful in only a few rare cases and there are usually more standard ways to accomplish what you want. For instance, in the above pull request would this not work?
SlowBuffer.prototype.__proto__ = Buffer.prototype; vs SlowBuffer.prototype = Object.create(Buffer.prototype); This gives SlowBuffer a prototype that inherits from the Buffer.prototype. And additional methods can still be added afterwards. Is this pattern a problem with objects surfaced from addons? If so, can someone give details? Basically the way to manipulate proto chains is Object.create and the way to retrieve the prototype of an instance is Object.getPrototypeOf. Unwieldy, I know, but standardized. And these shouldn't require any significant perf overhead compared to __proto__. If they do, the v8 team should be incentivized to make them faster. And we've seen that they are willing and able to do that. Having full fidelity to manipulate __proto__ of an object instance causes all sorts of headaches. It makes it really difficult to reason about the makeup of an objects properties. The example in the pull requests is simple enough obviously, but if the example is simple enough, __proto__ shouldn't even really be necessary. My feeling is that object properties should be Own properties, or they should be part of a sensible proto chain built with standard patterns. :Marco On Sunday, June 10, 2012 2:04:20 PM UTC-7, Brandon Benvie wrote: > > __proto__ is likely going to be in the ES6 spec as at least normative > optional. Recent discussions indicated there's some chance it will become > full-fledged part of the spec. > > http://wiki.ecmascript.org/doku.php?id=strawman:magic_proto_property > > https://mail.mozilla.org/pipermail/es-discuss/2012-May/022842.html > > On Friday, June 8, 2012 8:35:12 AM UTC-4, Tim Smart wrote: >> >> __proto__ is marked for depreciation in upcoming ecmascript specs. I >> think that is the most common reason you might find. >> >> Tim. >> >>
