These are chat archives for ramda/ramda

26th
Nov 2014
Graeme Yeates
@megawac
Nov 26 2014 02:08
Michael Hurley
@buzzdecafe
Nov 26 2014 02:09
just playing with this
pretty easy
Graeme Yeates
@megawac
Nov 26 2014 02:09
yeah, im subbed to a couple channels on here already
own 1 or 2
David Chambers
@davidchambers
Nov 26 2014 02:09
Hello, world!
Michael Hurley
@buzzdecafe
Nov 26 2014 02:11
hey
ramda is trending on github :-)
Graeme Yeates
@megawac
Nov 26 2014 02:51
the 1000 star gap, or did i miss a blog post
Richard Seldon
@arcseldon
Nov 26 2014 02:54
こにちわ。
hello!
take it, it's ok to say stupid things on here occasionally.
@buzzdecafe - noticed ramda was trending yesterday.
Richard Seldon
@arcseldon
Nov 26 2014 03:00
had a thought.
we might not wish to support aliases directly, but perhaps in our docs we could reference alternate names the functions are known by, and potentially make these searchable on the docs site.
sort of like meta-data with a custom JSDoc annotation.
Michael Hurley
@buzzdecafe
Nov 26 2014 03:02
i suggested something similar, a .ramdarc for your build
but that would mean we had a build :smile:
Richard Seldon
@arcseldon
Nov 26 2014 03:03
Right! your aliases idea. but perhaps even if we dont have aliases.
we could still say, put butLast as meta-info into a custom annotation for the docs.
there maybe namespace issues in this whereby two languages have the same function name but for different implementations and so on.
and it could be a mistake taking this path.
but in theory, what a fantastic facility that would be.
Scott Sauyet
@CrossEye
Nov 26 2014 03:14
Although I could see that as a really nice way to customize the lib, I would hate to document it. And if we had to support APIs that varied for similar functionality... ughh!
Michael Hurley
@buzzdecafe
Nov 26 2014 03:23
how's the brain?
Richard Seldon
@arcseldon
Nov 26 2014 03:23
@CrossEye really appreciated your comment on github, you sort of bailed me out by bothering to respond.
lol. think its a case of good in theory, but hopeless in practice.
good to see raganwald visiting Ramda the other day.
yet to read his two books, but working my way there.
Richard Seldon
@arcseldon
Nov 26 2014 03:35
question - do we have an API function that does a findWhere on a list with a criteria object (not a predicate function) ?
this is the closest i found: R.find(R.propEq('a', 2))(xs);
Graeme Yeates
@megawac
Nov 26 2014 03:37
that looks good, I would probably use where myself
Richard Seldon
@arcseldon
Nov 26 2014 03:42
yep. R.where(spec, {w: 10, x: 2, y: 300}); just found that one at the bottom.
what threw me is lodash has "where" and "findWhere"
so i ticked off "where" as matching "where" as i compare our apis
then the next item was "findWhere"
Graeme Yeates
@megawac
Nov 26 2014 03:45
yeah, I hear you I was arguing to call it matches a little while ago
Richard Seldon
@arcseldon
Nov 26 2014 03:49
so in lodash where is equivalent to our where - returns all matches for criteria object.
find only returns the first item given a predicate functions.
and findWhere returns the first item given a criteria object.
hope i got that right.
have we covered all those bases in Ramda with equivalent functions...
where and find definitely covered.
Graeme Yeates
@megawac
Nov 26 2014 03:51
lodash.where([list], {spec}) ~~ R.filter(R.where({spec}), [list])
Richard Seldon
@arcseldon
Nov 26 2014 03:52
right, thanks.
Graeme Yeates
@megawac
Nov 26 2014 03:52
there's a couple gotchas but for the most part
Richard Seldon
@arcseldon
Nov 26 2014 03:55
agreed, but perhaps there is a gap there...
if you want to find and return the first item from a list, but you want to check several attributes...
you would have to filter the entire list?
Graeme Yeates
@megawac
Nov 26 2014 03:57
I believe there is a R.find
I haven't looked at the code base too closely for several months
Richard Seldon
@arcseldon
Nov 26 2014 03:57
yes. so compose propEq
or something as the criteria.
Graeme Yeates
@megawac
Nov 26 2014 03:58
yeah findWhere(data, spec) is ~~ R.find(R.where(<spec>))(data)
Richard Seldon
@arcseldon
Nov 26 2014 03:58
gotcha.
thanks a tonne. one of those days...
Graeme Yeates
@megawac
Nov 26 2014 03:59
i hear ya, im on a different sort of those days (my main proj cancelled)
Richard Seldon
@arcseldon
Nov 26 2014 04:05
hope that wasn't a project you were either excited about or paid well...
you freelance?
Graeme Yeates
@megawac
Nov 26 2014 04:06
nah im an intern, get to work on cooler stuff now anyway (openwebrtc here I come)
Richard Seldon
@arcseldon
Nov 26 2014 04:08
sounds cutting edge.
really look forward to ES6 being a reality and viable across web browsers.
Graeme Yeates
@megawac
Nov 26 2014 04:11
sometime next year*, anyway 6to5 is almost good enough much good enough for me at this point
Richard Seldon
@arcseldon
Nov 26 2014 04:13
agree, js is getting there.
and importantly, so are the browsers.
so what do think about two new high level "facade functions" for our API.
both collections category
where -> internally filter(where)
findWhere -> internally find(where)
Graeme Yeates
@megawac
Nov 26 2014 04:23
collections category throws me off cause of ~_~, but I'd be against it - theres already a number of methods in ramda and _ that would be better off composed
Richard Seldon
@arcseldon
Nov 26 2014 04:24
appreciate your views on this. are there tangible reasons why you think composing is better? is that to keep the API smaller and more understandable..
my thoughts being where and findWhere might be really frequently needed operations.
so its a bit of sugar...
ok, shall remember to use "list" as our terminology too.
Graeme Yeates
@megawac
Nov 26 2014 04:26
yeah, I'm a fan of a lean core. If I could rewrite _ from scratch it would be a bit different
Richard Seldon
@arcseldon
Nov 26 2014 04:30
one benefit of providing those, is that lodashers etc are already familiar with them.
but i see your point too.
we dont want to pollute the api with lots of things that basically can achieve hte same resutl.
@megawac you are just way too modest.
i see you really did write quite a chunk of underscore :)
Richard Seldon
@arcseldon
Nov 26 2014 04:35
your off the cuff remark almost got lost on me..
Richard Seldon
@arcseldon
Nov 26 2014 04:55
@megawac - dont know what time in the evening it is for you, but would love to hear a little about your experiences on the underscore project.
if you are offline , or otherwise dont wish to share that stuff np.
Scott Sauyet
@CrossEye
Nov 26 2014 19:25
Wasn't listening for the where discussion, but you should note that Ramda's where has some additional capabilities beyond what _ does. And I also believe it is missing some of _'s capabilities. It's far from a 1 : 1 match.
Richard Seldon
@arcseldon
Nov 26 2014 21:36
@CrossEye - good day to you. 6 am here.
was mulling over this one overnight..
and considering too what @megawac was saying which makes a lot of sense.
playing devils advocate... (which we love to do in our industry) however i would like to share a couple of observations only.
is the purpose of Ramda to provide a practical API that is as high level as possible?
because in that regards we are being slightly inconsistent with composing filter(where), and find(where).
for instance, project, chain (flatmap) etc do internal composition right?
anyhow, no big deal, and fully appreciate we do have that covered albeit through composition of lower level api constructs.
Scott Sauyet
@CrossEye
Nov 26 2014 22:43
My take is that mostly we want to provide the basic functionality so that users can put together the functions they need. We don't need to have every convenience, every gloss, that might make their lives just that little bit easier as long as the functionality is available. But that does not mean that we would avoid sugar methods simply because the user could define them herself. Sugar is often what makes the dish more tasty. Something like chain is included for a very specific reason: we're trying to maintain compatibility with the FantasyLand spec. So I'm afraid it's not a compelling, "The is our only way" answer. But I really think that the nuances are important. We are trying to be a useful library, while retaining some sense of dignity.
Richard Seldon
@arcseldon
Nov 26 2014 23:34
Got it.