Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Set prop and path#451

Merged
CrossEye merged 6 commits intoramda:masterfrom
CrossEye:setPropAndPath
Oct 26, 2014
Merged

Set prop and path#451
CrossEye merged 6 commits intoramda:masterfrom
CrossEye:setPropAndPath

Conversation

@CrossEye
Copy link
Member

To go along with Lenses, I'd like to revisit the idea of pure setters.

Ping #398

ramda.js Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

setProp is in impure extension, so someone needs a new name

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could name this function R.assoc after clojure.core/assoc. This function associates a key–value pair with a map.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

assoc sounds good

@davidchambers
Copy link
Member

I'd prefer a path to be of type [String] rather than (a .-separated) String. It'd necessitate more—ahem—typing, but it's a richer representation of a path and could be used even with property names containing . characters.

ramda.js Outdated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This still will call spit each time, see R.where for how to add a hook for the first item

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch. Will need to fix this.

@CrossEye
Copy link
Member Author

@davidchambers While [String] is certainly the more powerful API, this was never meant to be a full-fledged any-possible property name parser.

But perhaps we could have both in a reasonable way, using a different name than path which is already pretty well claimed for this style by things like path, pathOn, and pathEq. But maybe we could have these call underlying route functions or some such...

This was referenced Oct 19, 2014
ramda.js Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overriding the specified property with the given value

This phrase, along with the function's name, imply the function is to be used for setting the value of an existing property. The property needn't exist, though. In fact, "adding" to a map might be the more common operation.

@CrossEye CrossEye mentioned this pull request Oct 24, 2014
CrossEye added a commit that referenced this pull request Oct 26, 2014
@CrossEye CrossEye merged commit d87db65 into ramda:master Oct 26, 2014
@CrossEye CrossEye deleted the setPropAndPath branch October 26, 2014 22:35
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.map won't work in ES3

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, damn. Not thinking straight.

I'll have to update for that.

CrossEye added a commit that referenced this pull request Oct 26, 2014
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

Successfully merging this pull request may close these issues.

4 participants