Marco, That option won't work in this case, because we need SlowBuffer.prototype to be the exact same object returned from C++.
It could be worked around, but would be even worse (in our estimation, at least) than using __proto__. Obviously that could change in a future version of V8 if __proto__ usage becomes slow or unsupported. But in general, I agree with all the very good points you make here, which is why I commented initially that __proto__ setting is against the rules, but in this case, the cost of breaking the rule is lower than the cost of following it. On Mon, Jun 11, 2012 at 12:06 PM, Marco Rogers <marco.rog...@gmail.com> wrote: > 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. >>> >
