That makes sense. That got me to thinking if there was a way to have the SlowBuffer properly inherit from Buffer in C++ land. Essentially do the equivalent of Object.create in C++ land *before* you add the native methods to the SlowBuffer.prototype.
Yes that approach is even less simple and transparent. I agree that __proto__ wins in this case. But that might point to deficiencies in the v8 api and it would be interesting to explore how it could be improved. But then I took a closer look at what was going on with Buffer and SlowBuffer. There's lots of bad juju there :) It looks like that whole situation is kinda screwed and it's best to keep things as simple as possible. :Marco On Monday, June 11, 2012 3:33:38 PM UTC-7, Nathan Rajlich wrote: > > Marco, > > The reason Object.create() wouldn't work in this case is because we don't > want to overwrite the native C++ binding functions from the "native" > SlowBuffer.prototype. > > We could have gotten away with Object.create() if we 1) save a reference > to the original SlowBuffer.prototype, then 2) overwritten > SlowBuffer.prototype using Object.create(), and finally 3) loop over the > original prototype and copy over all properties manually. > > So for brevity's sake, __proto__ wins here. > > On Mon, Jun 11, 2012 at 1:17 PM, Marco Rogers <[email protected]>wrote: > >> >>> That option won't work in this case, because we need >>> SlowBuffer.prototype to be the exact same object returned from C++. >>> >>> >> Interesting. Can you elaborate on this? Is it due to the weirdness with >> retrieving the right "this" object when in C++ land? >> >> :Marco >> > >
