You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Buffer + ES6] Lose the child's class method when extending Buffer in ES6 class style #3739
'use strict';classChildextendsBuffer{constructor(n){super(n);}foo(){console.log('gotcha!');}}letchild=newChild(4);child.foo();//=> TypeError: child.foo is not a function
I'm not sure how difficult is this problem to fix, but I would be happy if the above code works...
Just wrote a conceptual patch to get this working, but haven't been able to remove the performance hit from the current case. Will continue to work on this.
@trevnorris It is surprising to me that where to fix is JavaScript code. Just looked over c1bc39426d75242da156901a21971c820e2dc686, I wonder if perhaps Object.setPrototypeOf slows the performance as noted in MDN, but I'm not sure...
@hashedhyphen The use of Object.setPrototypeOf() is definitely a hit, but we're incurring that cost regardless (since it must be used on Uint8Array() instance). The extra cost comes from accessing new.target. Though my implementation is the first thing that popped out (took most the effort figuring out all the places where it needed to happen) and can probably be easily made faster.
Did the proposed fix above ever go in? I'm running into the same problem on Node v7.10.0
Tims-MBP:nodesandbox techten$ cat buffertest.js
'use strict';
class Child extends Buffer {
constructor(n) {
super(n);
}
foo() {
console.log('gotcha!');
}
}
let child = new Child(4);
child.foo();
Tims-MBP:nodesandbox techten$ node buffertest.js
/Users/techten/Documents/nodesandbox/buffertest.js:14
child.foo();
^
TypeError: child.foo is not a function
at Object.<anonymous> (/Users/techten/Documents/nodesandbox/buffertest.js:14:7)
at Module._compile (module.js:571:32)
at Object.Module._extensions..js (module.js:580:10)
at Module.load (module.js:488:32)
at tryModuleLoad (module.js:447:12)
at Function.Module._load (module.js:439:3)
at Module.runMain (module.js:605:10)
at run (bootstrap_node.js:427:7)
at startup (bootstrap_node.js:151:9)
at bootstrap_node.js:542:3
Tims-MBP:nodesandbox techten$ node -v
v7.10.0
Activity
trevnorris commentedon Nov 10, 2015
Just wrote a conceptual patch to get this working, but haven't been able to remove the performance hit from the current case. Will continue to work on this.
hashedhyphen commentedon Nov 10, 2015
@trevnorris Thank you for your quick responce! I'm looking forward to reflecting the patch to a stable version <3
trevnorris commentedon Nov 10, 2015
For reference, here's the patch and branch of the conceptual fix: trevnorris@c1bc394
hashedhyphen commentedon Nov 10, 2015
@trevnorris It is surprising to me that where to fix is JavaScript code. Just looked over c1bc39426d75242da156901a21971c820e2dc686, I wonder if perhaps Object.setPrototypeOf slows the performance as noted in MDN, but I'm not sure...
trevnorris commentedon Nov 10, 2015
@hashedhyphen The use of
Object.setPrototypeOf()is definitely a hit, but we're incurring that cost regardless (since it must be used onUint8Array()instance). The extra cost comes from accessingnew.target. Though my implementation is the first thing that popped out (took most the effort figuring out all the places where it needed to happen) and can probably be easily made faster.hashedhyphen commentedon Nov 10, 2015
@trevnorris I see. Thanks to your kindness, I was able to learn Node's inside more!
jasnell commentedon Mar 22, 2016
Assuming there's no further reason to keep this one open. Closing!
techtenk commentedon Aug 29, 2017
Did the proposed fix above ever go in? I'm running into the same problem on Node v7.10.0
test: rename test-regress-nodejsGH-3739
test: name test files appropriately
test: name test files appropriately
test: name test files appropriately
test: name test files appropriately
test: name test files appropriately