3 ms·
> here’s the kicker — if you overwrite a non-enumerable property, e.g. Array.prototype.sort = whatever, it remains non-enumerable. One thing I never understood
by shawnz 4y ago
> here’s the kicker — if you overwrite a non-enumerable property, e.g. Array.prototype.sort = whatever, it remains non-enumerable.
One thing I never understood about this problem: Why not change the behavior so that overriding non-enumerable properties makes them enumerable? That seems to be the behavior that library developers (e.g. MooTools) were already expecting anyway.
- JonathonW 4y agoMy guess is that they don't do that because that would change behavior for developers that are intentionally overriding existing methods-- like one might do if monkey-patching a method to work around a bug, or polyfill newer functionality, or add instrumentation. Basically, anything they could do here is a behavior change for someone. So, if they insist on not breaking things for anyone, the only option they have available (short of moving towards Windows-style app-specific compatibility workarounds) is to not change anything here, and just use a different name for the new method.
- bobbylarrybobby 4y agoDoesn’t that break things for the MooTools equivalent(s) that called the method `flat`?
- eyelidlessness 4y agoYes. At a certain point you stop searching and move forward. Which is what many other comments are asking for without realizing the scope of what would break at the give-up point alternatives they prefer.
- shawnz 4y agoThat's exactly what I would like to know -- what are the trade-offs involved in going with my preferred solution of changing modified non-enumerable properties to be enumerable? Every possible solution to the problem could create breakage somewhere, so what is the breakage that would be created with this solution and why is it less favourable than the solution they ended up with?
- deleted 4y ago[deleted]
- rezonant 4y agoMooTools is simply setting a value to a property that did not exist before the assignment. It isn't using Object.defineProperty() to create the property. You cannot call Object.defineProperty() twice for the same property (it throws an error). If assigning a value to a property that was previously defined as non-enumerable were to make it enumerable, then the very act of defining a property would have no value, except in the case where you are making a read-only property (ie using the "writable: false" option for Object.defineProperty).
- shawnz 4y agoYou can specify the value as part of the options to defineProperty, and also it is legal to call defineProperty twice on the same property but with a different value.