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

separate R.where into two simpler functions: R.where and R.whereEq #1036

Merged
merged 1 commit into from May 8, 2015

Conversation

Projects
None yet
4 participants
@davidchambers
Member

davidchambers commented Apr 20, 2015

Closes #1032

This is the alternative to #1034. If we decide we want both functions we need to decide what to name them. :)

Show outdated Hide outdated test/where.js
Show outdated Hide outdated src/where.js
@buzzdecafe

This comment has been minimized.

Show comment
Hide comment
@buzzdecafe

buzzdecafe Apr 20, 2015

Member

IMO where is about specifying an interface that the input object must satisfy, not that the object's individual properties must satisfy in isolation.

Member

buzzdecafe commented Apr 20, 2015

IMO where is about specifying an interface that the input object must satisfy, not that the object's individual properties must satisfy in isolation.

@megawac

This comment has been minimized.

Show comment
Hide comment
@megawac

megawac Apr 21, 2015

Contributor

I'm fine with this as long as whereEq is included

whereEq = compose(where, mapObject(eq))
Contributor

megawac commented Apr 21, 2015

I'm fine with this as long as whereEq is included

whereEq = compose(where, mapObject(eq))
@CrossEye

This comment has been minimized.

Show comment
Hide comment
@CrossEye

CrossEye Apr 21, 2015

Member

Damn, it hadn't hit me how straightforward that conversion was:

whereEq = compose(where, mapObject(eq))

Nice.

Member

CrossEye commented Apr 21, 2015

Damn, it hadn't hit me how straightforward that conversion was:

whereEq = compose(where, mapObject(eq))

Nice.

@svozza svozza referenced this pull request Apr 21, 2015

Closed

Highland.js Integration #1037

@davidchambers

This comment has been minimized.

Show comment
Hide comment
@davidchambers

davidchambers Apr 23, 2015

Member

Shall I add R.whereEq?

Member

davidchambers commented Apr 23, 2015

Shall I add R.whereEq?

@CrossEye

This comment has been minimized.

Show comment
Hide comment
@CrossEye

CrossEye Apr 24, 2015

Member

I could be happy with this version of where alongside a whereEq. But I believe @buzzdecafe still might have some reservations about it.

Member

CrossEye commented Apr 24, 2015

I could be happy with this version of where alongside a whereEq. But I believe @buzzdecafe still might have some reservations about it.

@buzzdecafe

This comment has been minimized.

Show comment
Hide comment
@buzzdecafe

buzzdecafe Apr 24, 2015

Member

not reservations. just not seeing the point particularly.

Member

buzzdecafe commented Apr 24, 2015

not reservations. just not seeing the point particularly.

@CrossEye

This comment has been minimized.

Show comment
Hide comment
@CrossEye

CrossEye Apr 24, 2015

Member

I say yes, then. Two simple functions beat one complex function hands-down.

Member

CrossEye commented Apr 24, 2015

I say yes, then. Two simple functions beat one complex function hands-down.

@davidchambers davidchambers changed the title from simplify R.where to separate R.where into two simpler functions: R.where and R.whereEq May 4, 2015

@davidchambers

This comment has been minimized.

Show comment
Hide comment
@davidchambers

davidchambers May 4, 2015

Member

I've added R.whereEq.

Member

davidchambers commented May 4, 2015

I've added R.whereEq.

* spec's own properties, accessing that property of the object gives the same
* value (in `R.eq` terms) as accessing that property of the spec.
*
* `whereEq` is a specialization of [`where`](#where).

This comment has been minimized.

@davidchambers

davidchambers May 4, 2015

Member

Is this valid use of the word specialization?

@davidchambers

davidchambers May 4, 2015

Member

Is this valid use of the word specialization?

This comment has been minimized.

@CrossEye

CrossEye May 4, 2015

Member

I would say so.

@CrossEye

CrossEye May 4, 2015

Member

I would say so.

@davidchambers

This comment has been minimized.

Show comment
Hide comment
@davidchambers
Member

davidchambers commented May 7, 2015

@buzzdecafe

This comment has been minimized.

Show comment
Hide comment
@buzzdecafe

buzzdecafe May 7, 2015

Member

i don't mind the complexity of the original. i don't really object to this, but it doesn't excite me either. i expect this may break a lot of stuff that uses where at present.

this is nice: return where(mapObj(eq, spec), testObj);
but i wonder how it performs? that was the reason for the nastiness of the original.

Member

buzzdecafe commented May 7, 2015

i don't mind the complexity of the original. i don't really object to this, but it doesn't excite me either. i expect this may break a lot of stuff that uses where at present.

this is nice: return where(mapObj(eq, spec), testObj);
but i wonder how it performs? that was the reason for the nastiness of the original.

@davidchambers

This comment has been minimized.

Show comment
Hide comment
@davidchambers

davidchambers May 7, 2015

Member

i expect this may break a lot of stuff that uses where at present.

Certainly. In most cases, users will need to replace R.where with R.whereEq:

-R.where({x: 1, y: 2})
+R.whereEq({x: 1, y: 2})

In each of the remaining cases, each non-function value in the spec must be wrapped with R.eq:

-R.where({x: 1, y: 2, z: R.gte(R.__, 0)})
+R.where({x: R.eq(1), y: R.eq(2), z: R.gte(R.__, 0)})
Member

davidchambers commented May 7, 2015

i expect this may break a lot of stuff that uses where at present.

Certainly. In most cases, users will need to replace R.where with R.whereEq:

-R.where({x: 1, y: 2})
+R.whereEq({x: 1, y: 2})

In each of the remaining cases, each non-function value in the spec must be wrapped with R.eq:

-R.where({x: 1, y: 2, z: R.gte(R.__, 0)})
+R.where({x: R.eq(1), y: R.eq(2), z: R.gte(R.__, 0)})
@CrossEye

This comment has been minimized.

Show comment
Hide comment
@CrossEye

CrossEye May 8, 2015

Member

Sorry, I thought I'd made it clear that I was in favor of this.

I do think that sometime soon, we'll have to look at the basic implementation. If I'm not mistaken, in the Great Curry Debacle of 2014, we reset this one in such a way that it might have lost some of the benefits that had been gained by the initial manual currying we had done. This one was the function that showed us the need for changes to our old currying, and it had some interesting behavior...

Member

CrossEye commented May 8, 2015

Sorry, I thought I'd made it clear that I was in favor of this.

I do think that sometime soon, we'll have to look at the basic implementation. If I'm not mistaken, in the Great Curry Debacle of 2014, we reset this one in such a way that it might have lost some of the benefits that had been gained by the initial manual currying we had done. This one was the function that showed us the need for changes to our old currying, and it had some interesting behavior...

buzzdecafe added a commit that referenced this pull request May 8, 2015

Merge pull request #1036 from davidchambers/where-pred
separate R.where into two simpler functions: R.where and R.whereEq

@buzzdecafe buzzdecafe merged commit 75cc61b into ramda:master May 8, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@megawac

This comment has been minimized.

Show comment
Hide comment
@megawac

megawac May 8, 2015

Contributor

Let's just make sure this is bold, highlighted, underlined in change log as
it will break a good amount of code
On May 8, 2015 10:46 AM, "Michael Hurley" notifications@github.com wrote:

Merged #1036 #1036.


Reply to this email directly or view it on GitHub
#1036 (comment).

Contributor

megawac commented May 8, 2015

Let's just make sure this is bold, highlighted, underlined in change log as
it will break a good amount of code
On May 8, 2015 10:46 AM, "Michael Hurley" notifications@github.com wrote:

Merged #1036 #1036.


Reply to this email directly or view it on GitHub
#1036 (comment).

@buzzdecafe

This comment has been minimized.

Show comment
Hide comment
@buzzdecafe

buzzdecafe May 8, 2015

Member

yep, totally agree

Member

buzzdecafe commented May 8, 2015

yep, totally agree

@davidchambers davidchambers deleted the davidchambers:where-pred branch May 8, 2015

@buzzdecafe

This comment has been minimized.

Show comment
Hide comment
@buzzdecafe

buzzdecafe May 8, 2015

Member

not sure what to make of this: http://jsperf.com/mapobj-test

Member

buzzdecafe commented May 8, 2015

not sure what to make of this: http://jsperf.com/mapobj-test

@davidchambers

This comment has been minimized.

Show comment
Hide comment
@davidchambers

davidchambers May 8, 2015

Member

I could certainly get behind a more efficient implementation. It was API complexity this pull request sought to reduce.

Member

davidchambers commented May 8, 2015

I could certainly get behind a more efficient implementation. It was API complexity this pull request sought to reduce.

return _satisfiesSpec(spec, parsedSpec, testObj);
for (var prop in spec) {
if (_has(prop, spec) && !spec[prop](testObj[prop])) {

This comment has been minimized.

@megawac

megawac May 9, 2015

Contributor

Any reason you're not using keys here (it'd be faster)?

@megawac

megawac May 9, 2015

Contributor

Any reason you're not using keys here (it'd be faster)?

This comment has been minimized.

@davidchambers

davidchambers May 9, 2015

Member

Sounds like a good idea to me!

@davidchambers

davidchambers May 9, 2015

Member

Sounds like a good idea to me!

@CrossEye CrossEye referenced this pull request Jan 30, 2016

Merged

Implement applySpec #1592

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment