| 00:01 | <canadahonk> | i would assume that whatever hasOwnProperty does to check that the object has the property is the same thing hasOwn would do |
| 00:02 | <canadahonk> | the two are basically identical per spec iirc |
| 00:02 | <canadahonk> | yeah (https://tc39.es/ecma262/#sec-object.hasown, https://tc39.es/ecma262/#sec-object.prototype.hasownproperty) |
| 02:10 | <joyee> | I think that’s just a very peculiar case of Node.js core where there isn’t much benefit to change existing code to use Object.hasOwn() - if the code was written from scratch it probably would’ve used ObjectHasOwn because why not, the perf difference doesn’t really matter. But then if the code has always been using ObjectPrototypeHasOwnProperty then you also get the why if you want to change it, and the usual reasons you give to user code doesn’t apply to Node.js core: you use it to prevent a prototype lookup, well but in Node.js core that is already prevented with the primordials machinery, what’s more the machinery is built into a snapshot so the bind was done in build time, not runtime. This doesn’t generalize to normal user code, and isn’t much motivation for the VM to do anything per-se. |
| 02:23 | <joyee> | Also mass refactoring in Node.js core has a uncommon demotivating cost which is the LTS backport cost (imagine the conflicts this can cause when back porting the patch and any patch that touch related lines to v18, v20 and v22). This cost doesn’t generalize to uh…any software that doesn’t need to maintain three simultaneous LTS releases that will be alive for years. So it’s just an odd one out. |
| 18:04 | <snek> | i was going to update the code to get rid of the call to hasOwnProperty and then i found there isn't even any optimization path for hasOwnProperty except for within for-in loops |
| 18:04 | <snek> | so its not like its a super fast operation anyway |