Codestin Search App

davidchambers · 2015-03-05T07:56:26Z

Closes #637

This pull request introduces four new internal functions: _assoc, _assocPath, _dissoc, and _dissocPath. These are defined with as few dependencies as possible. _assoc, for example, has no dependencies whereas the existing assoc implementation depends on _extend, _map, createMapEntry, fromPairs, and keysIn!

Most significantly, this pull request changes the type of the path parameter from (dot-separated) String to [String], and updates the test suite accordingly.

davidchambers · 2015-03-05T08:00:33Z

src/internal/_assocPath.js

What should happen if path is []?

return a clone of obj

I'm thinking a no-op, just returning the obj supplied.

It's a question of philosophy. One can make an argument for either approach. One could argue that _assocPath (and by extension assocPath) should always return an object to which no one holds a reference. On the other hand one could argue that since Ramda promotes programming without mutation, cloning is unnecessary.

We should also consider the current behaviour of R.path:

assert.strictEqual(R.path('', obj), undefined);

undefined is what you get for path('x', {y: 1}), yes? Seems like the same situation, analogous to find. Another unsafe function, to be sure

On the other hand one could argue that since Ramda promotes programming without mutation, cloning is unnecessary.

That's the argument I would make. I don't see a reason to treat the top-level object any different from the sub-object properties, which are references.

noop is fine

buzzdecafe · 2015-03-05T12:17:56Z

we should also update path* to have the same api

CrossEye · 2015-03-05T12:28:04Z

Is this the first internal recursion in Ramda? We've been pretty gun-shy about it after Eweda's stack problems. I don't mind here. The paths should never be long enough to worry us, but we need to note it and be wary.

This should close another issue that's been open for a while, but I'm too tired to try to find it.

davidchambers · 2015-03-05T17:34:29Z

we should also update path* to have the same api

Good catch.

R.pathOn doesn't make sense now that we're specifying path as a list. Shall we remove it?

davidchambers · 2015-03-05T17:35:59Z

test/path.js

We should agree on how this should evaluate.

seems to me to be the same case as this: assert.strictEqual(R.path(['j', '1'], obj), undefined);

buzzdecafe · 2015-03-05T17:57:58Z

R.pathOn doesn't make sense now that we're specifying path as a list. Shall we remove it?

yes. do we need to deprecate first?

davidchambers · 2015-03-05T18:31:18Z

do we need to deprecate first?

I don't think so. We're making breaking changes to R.path, R.pathEq, R.assocPath, and R.dissocPath. I don't see much value in preserving the old behaviour of R.pathOn for one release. Furthermore I'm against having the old R.pathOn function in a release alongside the new path functions.

buzzdecafe · 2015-03-05T18:43:12Z

agreed. this change has been in the air for a while anyways

TheLudd · 2015-03-05T20:53:52Z

Just curious, why is this preferred?

buzzdecafe · 2015-03-05T21:24:31Z

Just curious, why is this preferred?

e.g. imagine you are modeling a filesystem as an object, you could have keys with '.' in them.

buzzdecafe · 2015-03-05T22:22:02Z

🐄

davidchambers · 2015-03-06T07:21:52Z

src/internal/_path.js

I don't love the obj == null guard, but removing it is a matter for a separate pull request.

TheLudd · 2015-03-06T09:27:29Z

@buzzdecafe

e.g. imagine you are modeling a filesystem as an object, you could have keys with '.' in them.

good point

davidchambers · 2015-03-06T19:50:45Z

src/internal/_pickBy.js

_pickBy is no longer used (except in pickBy).

davidchambers · 2015-03-06T19:52:06Z

This pull request is ready for a final review.

buzzdecafe · 2015-03-06T20:03:03Z

src/internal/_assocPath.js

😺

elegant

buzzdecafe · 2015-03-06T20:14:39Z

🐄

change path functions to operate on lists of strings

witoldsz · 2015-05-17T13:32:06Z

It's too bad you did not let users using a path as a string to maintain backward compatibility and for simplicity (Ramda could internally split it on "dot" if an argumet was a string).

Sometimes it's so much easier and shorter to be able to specify "a.b.c.d" instead of awkward array notation (which is in itself useful some other times).

CrossEye · 2015-05-17T14:07:31Z

TiIt's actually for reasons of simplicity (as opposed to those of ease) that we choose for our API not to do such different things on different input types.

However I'm with you on how nice the string-based API was compared to the array-based one. But I couldn't argue against the additional flexibility of the current approach. Luckily, it should be easy to write your own version on top of the existing one.

witoldsz · 2015-05-17T22:52:14Z

I wish I had convinced you to make an exception, for the sake of "a practical" adjective describing the library at the front page :)
Thanks for the Simple Made Easy link.

CrossEye · 2015-05-18T01:16:47Z

I wish I had convinced you to make an exception, for the sake of "a practical" adjective describing the library at the front page

I discuss the notion of what we mean by "practical" in The Philosophy of Ramda and further in #1002 (comment) . I think there's a good reason not to do what you're suggesting, even though I initially argued for it as well, and even though we did it that way at first.

A number of our functions are dynamically dispatched, and we internally supply the version that works for lists or for plain objects. And we offer tranduced versions of many of our functions. But other than that, we don't vary our behavior based on argument type. I think that's a pretty clean line to draw. But creating a version that works the way you want should be as simple as:

var path = R.useWith(R.path, R.split('.'), R.identity);
path('a.b.c', {a: {b: {c: 'foo', d: 'bar'}}}); //=> 'foo'

davidchambers force-pushed the assoc-path branch from ff01db7 to bbc9e07 Compare March 5, 2015 07:59

davidchambers reviewed Mar 5, 2015
View reviewed changes

davidchambers force-pushed the assoc-path branch from bbc9e07 to 2b874e3 Compare March 5, 2015 17:32

davidchambers changed the title ~~change R.assocPath and R.dissocPath to take a list of strings~~ change R.path, R.assocPath, and R.dissocPath to take a list of strings Mar 5, 2015

davidchambers reviewed Mar 5, 2015
View reviewed changes

davidchambers force-pushed the assoc-path branch from 2b874e3 to d583642 Compare March 5, 2015 18:41

davidchambers changed the title ~~change R.path, R.assocPath, and R.dissocPath to take a list of strings~~ change path functions to operate on lists of strings Mar 5, 2015

davidchambers force-pushed the assoc-path branch from d583642 to 32a001c Compare March 6, 2015 07:19

davidchambers reviewed Mar 6, 2015
View reviewed changes

src/internal/_path.js

Copy link

Member Author

davidchambers Mar 6, 2015

Choose a reason for hiding this comment

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

I don't love the obj == null guard, but removing it is a matter for a separate pull request.

change path functions to operate on lists of strings

bfb4136

davidchambers force-pushed the assoc-path branch from 32a001c to bfb4136 Compare March 6, 2015 19:47

davidchambers reviewed Mar 6, 2015
View reviewed changes

src/internal/_pickBy.js

Copy link

Member Author

davidchambers Mar 6, 2015

Choose a reason for hiding this comment

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

_pickBy is no longer used (except in pickBy).

buzzdecafe reviewed Mar 6, 2015
View reviewed changes

src/internal/_assocPath.js

Copy link

Member

buzzdecafe Mar 6, 2015

Choose a reason for hiding this comment

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

😺

elegant

davidchambers added a commit that referenced this pull request Mar 7, 2015

Merge pull request #876 from davidchambers/assoc-path

e29cf51

change path functions to operate on lists of strings

davidchambers merged commit e29cf51 into ramda:master Mar 7, 2015

davidchambers deleted the assoc-path branch March 7, 2015 01:03

davidchambers mentioned this pull request Mar 8, 2015

0.11.0 upgrade guide #892

Closed

raine mentioned this pull request Oct 19, 2015

Alternate input style for R.path #1451

Closed

CrossEye mentioned this pull request Jul 29, 2016

Possible way to concisely create lens #1839

Closed

CrossEye mentioned this pull request Jun 7, 2018

Update the 'path' method to it could take a string as the 1st param. #2556

Closed

Uh oh!

Conversation

davidchambers commented Mar 5, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

buzzdecafe commented Mar 5, 2015

Uh oh!

CrossEye commented Mar 5, 2015

Uh oh!

davidchambers commented Mar 5, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

buzzdecafe commented Mar 5, 2015

Uh oh!

davidchambers commented Mar 5, 2015

Uh oh!

buzzdecafe commented Mar 5, 2015

Uh oh!

TheLudd commented Mar 5, 2015

Uh oh!

buzzdecafe commented Mar 5, 2015

Uh oh!

buzzdecafe commented Mar 5, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheLudd commented Mar 6, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

davidchambers commented Mar 6, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

buzzdecafe commented Mar 6, 2015

Uh oh!

witoldsz commented May 17, 2015

Uh oh!

CrossEye commented May 17, 2015

Uh oh!

witoldsz commented May 17, 2015

Uh oh!

CrossEye commented May 18, 2015

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants