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
Post by Andri MöllNon-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
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
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141002/612ce77c/attachment-0001.html>