Discuss
  • About the community extending native built-ins

About the community extending native built-ins

# Andrea Giammarchi (11 years ago)

Just to clarify, and this is not for Rick only:

On Wed, Oct 1, 2014 at 8:59 PM, Rick Waldron <waldron.rick at gmail.com> 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] WebReflection/eddy#event

# Andri Möll (11 years ago)

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

# Andrea Giammarchi (11 years ago)

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