-
Notifications
You must be signed in to change notification settings - Fork 2k
Splatted objects #815
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
Comments
I'm not a big fan of overloading |
This feature would be handy because copying an object's props over another is a very common operation. Our source code is no different--we even have two different helper fuctions that can be replaced by this. |
I really like this idea. Almost all of my libraries have some sort of merge helper. |
Like jashkenas, I believe this is too much responsibility for the |
An object is effectively a list of properties, for that matter. |
This doesn't make sense to me. As Jeremy said, this puts a pretty big burden on the splat operator. What's worse,
is valid shorthand for
would be...what? Here, I'd be happy to have a nice syntax for object merges, but this isn't the way to do it. |
A similar situation to |
It's not only that -- the Closing as a |
Yet another issue that's closed too fast, eh?
That's coming as well, of course.
Please provide links. Duplicate of what exactly? |
We already got splatted arrays
[a, b...]
. Now how about extending it to objects?The compilation of
{0: 1, o...}
would be something like:where
__mix
is defined as:The text was updated successfully, but these errors were encountered: