These are chat archives for ramda/ramda

9th
Mar 2015
Michael Hurley
@buzzdecafe
Mar 09 2015 00:40
I don't think top-to-bottom would work very well:
R
.
p
i
p
e
(
// etc.
)
Hardy Jones
@joneshf
Mar 09 2015 04:16
heh
@rue you could have something like that if you put a map on Function
Function.prototype.map = function(g) {
  var f = this;
  return function(x) {
    return g(f(x));
  };
};

var add1 = function(x) {
  return x + 1;
};

var times3 = function(x) {
  return x * 3;
};

var twentyTwo = add1
    .map(times3)
    .map(add1)
    (6);
or just open the R.pipe on one line, and put all the functions on each line
R.pipe(
  foo,
  bar,
  ...
);
Scott Sauyet
@CrossEye
Mar 09 2015 10:34
@paldepind: been offline for a few days
Scott Sauyet
@CrossEye
Mar 09 2015 10:40
I have yet to look closely at lodash-fp. I have a hard time taking it seriously, as its author had spent a fair bit of time on Ramda discussions criticizing our design decisions. Now he seems to be copying them. If it were just the auto-curry and parameter order, I might think he'd simply seen the light. But he has spent a great deal of time arguing for index parameters to such functions as map. Now this library doesn't have them. This makes me suspect an overdeveloped competitive streak. And I don't want to play those games.
Hardy Jones
@joneshf
Mar 09 2015 16:13
I'd like to think there's a time and place for both styles
but you get more generalized behavior by just having the one style
you can implement the index behavior with just unary map
of course, you could define the unary map in terms of a binary one as well
Ludwig Magnusson
@TheLudd
Mar 09 2015 16:16
@joneshf I don't thin CrossEye was saying one strategy was beter thant the other but rather that Dalton was arguing heavily against one style and then implemented a lib using that exact style
Hardy Jones
@joneshf
Mar 09 2015 16:18
ah
Scott Sauyet
@CrossEye
Mar 09 2015 16:19
Exactly.
Murphy Randle
@splodingsocks
Mar 09 2015 17:11
Hi, friends, I keep needing a deep merge, but as far as I can tell, R.merge is shallow only. What alternative do you suggest?
it seems like a common enough want that there's some other convenient way of doing it that I'm missing
Ludwig Magnusson
@TheLudd
Mar 09 2015 17:15
I don't think there is a function like this in ramda. I have used the extend module available on npm in the rare cases that I need deep merge. But that mutates input.
Murphy Randle
@splodingsocks
Mar 09 2015 17:15
okay cool. Yeah, the mutating input makes me sad
Ludwig Magnusson
@TheLudd
Mar 09 2015 17:15
It's not very ramdaish at all in any respect actually :)
Murphy Randle
@splodingsocks
Mar 09 2015 17:16
merging two objects and returning a merged copy?
Ludwig Magnusson
@TheLudd
Mar 09 2015 17:17
it is based on the jQuery extedn. It mutates the first parameter. So you can do extend({}, obj1,, obj2). Now neither obj1 or obj2 is mutated
actually, you need to do extend(true, {}, obj1, obj2) for deep merge
But maybe the ramdans are up for a PR here..
Murphy Randle
@splodingsocks
Mar 09 2015 17:20
Yeah! I'd like to gauge interest before diving in and making a PR. The proposed API would be something like: R.mergeDeep(obj1, obj2) . A copy of obj1 with obj2's properties deeply merged on top would be returned
so neither obj1 nor obj2 would be mutated
Murphy Randle
@splodingsocks
Mar 09 2015 17:29
or maybe most people don't need a deep merge very often, like you TheLudd
John-David Dalton
@jdalton
Mar 09 2015 17:30
@TheLudd We created lodash-fp because we heard from some functional programming fans that lodash wasn’t functional enough, often citing our method signatures as an issue.
Ludwig Magnusson
@TheLudd
Mar 09 2015 17:30
heeh
I use it pretty rarely but I do indeed need it sometimes
Murphy Randle
@splodingsocks
Mar 09 2015 17:31
@jdalton, I've been a big fan of lodash in the past, but I started to prefer that my input not be mutated. Also, once I encountered ramda I really started to like the auto-curried thing
as far as I understand lodash-fp still mutates input, right?
Last time I checked there wasn't much documentation yet
John-David Dalton
@jdalton
Mar 09 2015 17:32
most methods in lodash/underscore are don't mutate
there are a few that do
Murphy Randle
@splodingsocks
Mar 09 2015 17:33
that was part of my confusion, some do, so I always had to run to the docs to see if it were a mutating method
John-David Dalton
@jdalton
Mar 09 2015 17:33
they're documented too
Murphy Randle
@splodingsocks
Mar 09 2015 17:33
yeah, but it's was always a pain to have to go look up and see which were
John-David Dalton
@jdalton
Mar 09 2015 17:33
if you've used the lib with some regularity it becomes second nature.
Murphy Randle
@splodingsocks
Mar 09 2015 17:34
I know you can't change that and keep compat with underscore, though
John-David Dalton
@jdalton
Mar 09 2015 17:34
we aren't locked into underscore compat
Murphy Randle
@splodingsocks
Mar 09 2015 17:34
Cool! I think it'd be really a great idea for lodash / lodash-fp to subscribe to a no-input-mutation policy
John-David Dalton
@jdalton
Mar 09 2015 17:35
If it becomes a big enough request we'll consider it
we're pretty fluid when it comes to catering to devs which is why we offer amd/node/commonjs exports, fp, & modularized forms
Murphy Randle
@splodingsocks
Mar 09 2015 17:36
very cool. Cast in my vote for no mutations!
but ramda is pretty awesome
the only think I've missed from lodash so far is deep merge
John-David Dalton
@jdalton
Mar 09 2015 17:36
you can get that using the modularized form
Murphy Randle
@splodingsocks
Mar 09 2015 17:37
oh, that's way cool!
John-David Dalton
@jdalton
Mar 09 2015 17:37
then use _.rearg, _.curry, _.ary packages to auto curry flip it's args
Murphy Randle
@splodingsocks
Mar 09 2015 17:37
I was actually just wishing that were a thing, and it is!
Murphy Randle
@splodingsocks
Mar 09 2015 17:39
very cool
thanks!
John-David Dalton
@jdalton
Mar 09 2015 17:39
In v3 you can cherry pick from the primary package too, require('lodash/function/rearg') which browserifies/webpacks nicely.
Murphy Randle
@splodingsocks
Mar 09 2015 17:39
that's awesome!
John-David Dalton
@jdalton
Mar 09 2015 17:40
So you don't have to go all or nothing, you can mix and match, modules rock!
Murphy Randle
@splodingsocks
Mar 09 2015 17:40
On Saturday I ended up doing the lazy thing and converting both of my objects to Immutable.js maps and then merged
yeah, this is super cool.
John-David Dalton
@jdalton
Mar 09 2015 17:44

Soon you'll be able to do:

var convert = require('lodash-fp/convert'),
      merge = convert('merge', require('lodash.merge'));

and get the auro-curried-flipped-arg form.

Murphy Randle
@splodingsocks
Mar 09 2015 17:45
oh, that's cool too
John-David Dalton
@jdalton
Mar 09 2015 17:45
(you can do it now, but it's not official yet)
and or course with lodash-fp you still get dat perf http://jsperf.com/currying-cost/2#chart=bar
Hardy Jones
@joneshf
Mar 09 2015 19:17
@murphyrandle what sort of things are you deep merging?
Murphy Randle
@splodingsocks
Mar 09 2015 20:40
@joneshf I've got an object that represents the state of all the data in an app, and I'm merging the client state together with the state from the server
Jethro Larson
@jethrolarson
Mar 09 2015 21:21
Redacted comment that was also in poor taste.
Eero Saynatkari
@rue
Mar 09 2015 21:36
@joneshf Yes, that’s exactly what I meant by top-down :) I prefer pipe on one line, too, because function application is typically left-associative, but in practice I always use top-down. But, then, I tend to format my code very vertically anyway.