Thanks Andri, but about not touching it, `eddy.js` is a perfectly fine, working, and not that obtrusive (not enumerable, not even in IE8) example where nothing bad ever happened (so far) because when developers use `obj.emit()` they expect a node.js like `emit` while when they use `node.trigger()` they expect a `trigger` like approach.
These are de-facto standards, it would be very annoying if tomorrow ES will create an `Object` method called `emit` that does something else and node.js chaps would be very confused by that (almost everything in node inherits EventEmitter, that's IMO a good case for an `Object.prototype` lazy promotion so that any object could become able to listen and emit events only when and if needed) Other shortcuts (just few of them) have been already marked here as "won't ever land" and the direction seems to be subclassing ... I haven't seen much effort in improving the `Object.prototype` in ES6 or ES7, actually I've seen none, 'cause that's the untouchable root nobody wants to touch indeed since 90s Accordingly, why wouldn't I make it convenient for my daily tasks? These days I kinda feel it's safer for a library to touch `Object.prototype` rather than `Array` one, with still changes and/or updates (see `Array#contains`) ... 'cause being behind `Array` won't ever compromise `Array` itself, right? As example, if you think about it, `.contains` in an object would be handy and nice to know if some property is part of some own key. In a String it would be nice to know if it has the match instead of using ~indexOf or RegExp ... and so on Anyway, without loosing focus, I'd like to know other TC39 members opinion too and also if there is any concrete plan to change in ES.next anything about `Object.prototype` Thanks and Best Regards On Thu, Oct 2, 2014 at 10:33 AM, Andri Möll <[email protected]> wrote: > 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 > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
