Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Must you modify core prototypes? e.g. Object.prototype #70

Closed
buchanae opened this issue Apr 30, 2014 · 6 comments
Closed

Must you modify core prototypes? e.g. Object.prototype #70

buchanae opened this issue Apr 30, 2014 · 6 comments

Comments

@buchanae
Copy link

I notice you "shim" a bunch of things onto core prototypes, e.g. Object.addEach. Is that really necessary? Isn't it taboo to modify Object.prototype?

Can you at least point me to the ECMAScript standard that is planning to implement Object.addEach and all its friends? I can't find it.

I want to use your library, but honestly I get a bad feeling about all this modification of core prototypes.

@kriskowal
Copy link
Member

There is not standard that introduces Object.addEach, Object.compare, Object.equals, or Object.clone. Object.is was proposed, but has not been reified. It is safe to assume that Object.hash will never become a standard, and is only necessary for polyfilling Map and Set. When it comes to polyfills and prollyfills, it is always hard to tell when to lead and when to follow. Array.prototype.find is one polyfill I got wrong, (I correctly anticipated its standardization but did not anticipate the same semantics) which has been fixed for the unreleased v2 branch.

TC39 looks to code in the wild for patterns to standardize. As such, there is a bit of a chicken and egg problem. See https://www.youtube.com/watch?v=xL3xCO7CLNM

To adopt Collections does mean buying into certain ideas for future standards.

@kriskowal
Copy link
Member

(To be clear, I closed the issue because I don’t foresee acting on this. It is not to say that the issue is closed to discussion.)

@buchanae
Copy link
Author

buchanae commented May 1, 2014

Thanks for the quick and clear response. At least this development decision/philosophy is documented here now, and here for discussion.

Personally, I disagree. You're imposing unnecessary risk on codebases by making global modifications. Will it result in many terrible headaches, or a few minor ones? I can't say, but I'm fairly confident it will bite someone. If it can be done a different way without much trouble and reduce the risk, why not do it that way?

@JHumphreyJr
Copy link

This package definitely interferes with the Array.prototype.find polyfill. Any ETA on a V2 release to resolve this issue?

@kriskowal
Copy link
Member

I can’t offer an estimate, but I am moving in this direction on v2 7c674d4

@timruffles
Copy link
Contributor

I think it'd be at least good to document this. It's definitely a "principle of least surprise" violation (e.g I was very confused by seeing [].set() in the source) considering the JS ecosystem aversion to extending core types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants