The reason __proto__ was used in this case was because SlowBuffer.prototype already had properties set on it from C++-land, which we don't want to overwrite.
Indeed, we could read the values from the native SlowBuffer.prototype, call Object.create() to inherit from Buffer, then copy the native properties back over to the new prototype. But I figured in this case 1 line of code wins. As far as an official stance... I don't want to speak "officially", but there is already one other place where we set __proto__, and that's on the "process" object to make it inherit from EventEmitter. Arguably we could do that same "proper" thing there, and create a true EventEmitter instance in JS-land and have it be "process", and we copy over the native "process" properties to that at startup, but we don't. I couldn't tell you why, but I guess startup speed might be a minute part of it, so I guess the same could go for Buffer, since that's used at startup as well. On Mon, May 7, 2012 at 12:30 PM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > I noticed in https://github.com/joyent/node/pull/3228 TooTallNate used > __proto__ but anticipated some resistance to it. Does Node core have a > position on __proto__ vs. Object.create? I'm really just curious, and > didn't want to clog the pull request with an unrelated question. > > The line in question would become > > SlowBuffer.prototype = Object.create(Buffer.prototype); > > >
