Non-enumerability provides no protection against erroneous behavior because
there’s another, more popular code construct: the property access. If some code
takes in an object with the signature {emit: String} and someone happened to
add a function “emit" to Object.prototype, well, something weird _is_ going to
happen.I wouldn't support asking everyone to do hasOwn checks before accessing properties either. Not to mention being cumbersome, it would inhibit a far more useful feature of JavaScript — prototypical inheritance. One can probably get away with extending Array.prototype, but the practice of touching Object.prototype should (to this day) be prevented before it hurts us all. Andri On Oct 2, 2014, at 11:55, Andrea Giammarchi <[email protected]> wrote: > Just to clarify, and this is not for Rick only: > > On Wed, Oct 1, 2014 at 8:59 PM, Rick Waldron <[email protected]> wrote: > > As a community we'll simply have to reject the use of code that directly > modifies built-ins. This is also not a very strong argument in the ES6 world > where built-ins can be subclassed. > > > I wonder if that "directly" means as enumerable assignment instead of using > `Object.defineProperty` in a non enumerable way or just any addiction to > native prototypes > > As stated in another thread, extending natives **is** a JavaScript thing and > people have done that since ever, most of ES5 methods came from who did it > because the community needed them, and when I've personally proposed methods > such `Object#boundTo`, `Object#on` and `Object#off` I've been told that would > have never landed in `Object.prototype` so I felt very safe in adding them in > `eddy.js` [1] and developers seemed to be very happy about it (they are > growing monthly, like ... doubling) > > I also believe if developers extend natives is because this pattern make > their life easier ... plus: literals always won against `new Something` and > for primitives values there's not even an equivalent since `new String`, as > example, is not the same as `"string"`. > > Bear in mind I am not saying it's a good thing and everyone should add random > meaningless or messed up methods to native prototypes and I believe these > should never conflict and must be updated/changed ASAP (major breaking > release) to match eventually new specifications avoiding `Array#contains` > like problems but I'd like to understand what's the official take from TC39 > members. > > Thank you > > [1] https://github.com/WebReflection/eddy#event-driven-js > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
