Implement applySpec

[asaf-romano]

Closes #1591

[davidchambers]

Could we use R.apply here instead?

[asaf-romano]

Sure, will do in the round.

By the way, I must say that this line is confusing:
https://github.com/ramda/ramda/blob/master/src/apply.js#L24

If it's intentionally trying to support mapping this to the global object, I guess that's fine*, but it better be documented (in the code), because it's easy to overlook that.

---

• Note that this makes the caller environment significant:

(function f() { return require("ramda").apply(function() { return this; }, []);  })(); // => Node's global object;
(function f() { "use strict"; return require("ramda").apply(function() { return this; }, []);  })() // => undefined

[CrossEye]

By the way, I must say that this line is confusing:
https://github.com/ramda/ramda/blob/master/src/apply.js#L24

If it's intentionally trying to support mapping this to the global object, I guess that's fine*, but it better be documented (in the code), because it's easy to overlook that.

That's not it. Most of our functions that manipulate functions use a similar technique to make it easier to use the generated functions in an OO context. It's pretty difficult right now to come up with a good example of why someone would want to do that with apply, but the point is that if the function supplied uses 'this' and the function generated ends up being used as an Object method, then because of this technique, we properly keep track of the this being used when calling the function.

This has always been more of a nice-to-have feature than something driving our API. But if it doesn't get in our way, it helps smooth the way for this library to interact with other JS code the user may have to work with.

[asaf-romano]

@CrossEye I see, I think it's broken though: http://bit.ly/1ZpEC37

[CrossEye]

Sure enough. I imagine some change to curry2 has caused this.

When I have some time, I'll try to dig into it and see if I can see why.

[asaf-romano]

Yep, it doesn't call .apply:
https://github.com/ramda/ramda/blob/master/src/internal/_curry2.js#L25

[asaf-romano]

The same issue applies to _curry3.

[asaf-romano]

Feedback would be nice ;)

[CrossEye]

Feedback would be nice ;)

Thanks for the poke. Behind, as ususal.

🌿 I really like this. I see it as quite useful, and not easily achievable with anything else we have.

I'm not sure I like the implicit recursion. It might be better to make it explicit:

R.applySpec({ unnested: R.always(0), nested: R.applySpec({ sum: R.add }) })(1, 2);
//=> {unnested: 0, nested: {sum: 3}}

But I'm not certain about this, mostly thinking aloud.

[asaf-romano]

The library is not consistent elsewhere:

R.evolve({ a: { b: R.inc } }, { a: { b: 1 } }) // => {"a": {"b": 2}}
R.where({ a: { b: R.gt(R.__, 0 ) } }, { a: { b: 0 } }) // throws "spec[prop] is not a function"

Practically speaking, it's been quite a few times where({ currentBehavior: { where: disappointedMe } }) (and somewhat surprised me, given how evolve works); On the other hand, I do find the recursive behavior of evolve very powerful.

As for our own implementation of applySpec: initially it wasn't recursive, but it quickly became clear that the recursive use case is very sound. Not exactly our use case, but consider a function that constructs a nicely nested object out of a flat DB-row result, something like this:

  const getUserInfo = pipeP(
    ...,
    applySpec({
      credentials: {
        userName: prop("user_name"),
        passowrd: pipe(prop("passowrd_enc"), ...)
      },
      lastActive: pipe(prop("last_active"), toDate),
      stats: {
         accessCount: pipe(...),
         ....
      },
      ...
    })
  );

If the "sub-specs" for credentials, stats and other properties aren't reusable (i.e. those objects don't stand by themselves), a non-recursive implementation would just add some unnecessary noise, somewhat hiding the author's intentions.

[CrossEye]

It was that inconsistency I knew we already had that was bothering me, although I hadn't yet tried to figure out exactly where each style was used.

I believe you're right. The recursive one is much more powerful for a spec, so long as we're only passing functions. where evolved from a different direction, and we couldn't have done this before #1036. But I would be in favor of making where recursive as well.

🌿

Any objections, anyone?