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

[davidchambers]

Closes #1032

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

[davidchambers]

I'd love to remove this special case.

[CrossEye]

👍

[davidchambers]

⚡

[buzzdecafe]

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]

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

whereEq = compose(where, mapObject(eq))

[CrossEye]

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

whereEq = compose(where, mapObject(eq))

Nice.

[davidchambers]

Shall I add R.whereEq?

[CrossEye]

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

[buzzdecafe]

not reservations. just not seeing the point particularly.

[CrossEye]

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

[davidchambers]

I've added R.whereEq.

[davidchambers]

Is this valid use of the word specialization?

[CrossEye]

I would say so.

[davidchambers]

((:bell:)) @buzzdecafe, @CrossEye

[buzzdecafe]

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]

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]

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...

[megawac]

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]

yep, totally agree

[buzzdecafe]

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

[davidchambers]

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

[megawac]

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

[davidchambers]

Sounds like a good idea to me!