Absorb type functions from https://github.com/enten/rcb

[char0n]

• create a pull request for rcb with note that it bacame part or ramda-adjunct

[KiaraGrouwstra]

I've just added some more functions to Ramda's Cookbook as well, feel free to add them if you'd like.

[char0n]

Thanks for the notice, the plan is to completely implement ramda cookbook into ramda-adjunct and cover it with tests. The speed of adding new utils is only limited by my time. I created issue #27 to track the progress on cookbook absorption.

[KiaraGrouwstra]

I noticed you mentioned the type functions from rcb in your LinkedIn article as well. I was wondering, had you considered settling for just using is?

[char0n]

@tycho01 Consider this usecase:

Create utils that I can reuse later. The main paradigm of functional programming.

const isString = is(String);
const isNotString = complement(isString);

vs replicate utils creation in places where you need it.

complement(is(String))

This is the point I was trying to make in my article; I guess unsuccessfully ;] I would rather create named aggregate utils that I can test. Using is for creating aggregate utils is absolutely valid, but I would like to test it, before I use it.

[KiaraGrouwstra]

I've just been using R.is(String), but I'll admit having functions in their own name (unlike that not of mine there) does help for that ES6 notation like I did with { String, Number } there.
Attempt to generalize...

// is.js
module.exports = R.pipe(R.toPairs, ([k, cls]) => [`is${k}`, R.is(cls)], R.fromPairs)({ String, Number });`
// { isString, isNumber }

// not.js
import * as isType from 'is.js';
export const not = R.map(R.complement, isType)
// not: { isString, isNumber }

Name class with R.not (if imported) aside, and I'm probably mixing up import/export statements in an attempt to keep things general too... eh, whatever. :P

[char0n]

Yes, that is one way of getting around. I personally preferred to define my functions staticaly so that I had complete control over them. Nevertheless we were doing basically the same thing. And I guess everybody is doing this, this way or another. Ramda adjunct solves this never ending wheel of reinvention by centralizing all such efforts and covering them with tests.

Do you feel like helping me with this effort by sending pull request from time to time ? ;]

[KiaraGrouwstra]

On type functions, half-assed compromise for settlers like me: let isnt = complement(is);. That said I'd totally be in favor of aintNo(String). 😄

But yeah, I'm all in favor of having a home for reusable functions not part of Ramda core. I do worry that "like Ramda but lower standards" may result in an identity crisis once this repo might inevitably for whatever reason start rejecting bits as out of scope itself, but yeah. Still better than Cookbook functions not having an npm-based home.

On another note, I personally tend to write using TypeScript, and would be inclined to use that to verify/annotate typings, then transpile down. I'd wonder if something like that might be a consideration here as well.

[char0n]

But yeah, I'm all in favor of having a home for reusable functions not part of Ramda core. I do worry that
"like Ramda but lower standards" may result in an identity crisis once this repo might inevitably for
whatever reason start rejecting bits as out of scope itself, but yeah. Still better than Cookbook functions
not having an npm-based home.

Agree with all your points. Let's see how it goes.

On another note, I personally tend to write using TypeScript, and would be inclined to use that to
verify/annotate typings, then transpile down. I'd wonder if something like that might be a
consideration here as well.

It might be considered. But let us ask ourselves what would be the real technical benefit here except the personal preference ? What we do here is point free functional composition, using jsdoc notation to generate a documentation from it. Where does typescript fits in ?

[KiaraGrouwstra]

So afaik, JSDoc's role lies in generating docs. What TypeScript could add is IDE autocomplete, as well as providing real-time (IDE + compile-time) sanity checks to ensure users aren't using the functions wrong, and better yet, also informing them what type the result will be (not in the general sense, as docs do, but specifically for the case of the parameters as supplied by them).

[char0n]

Isn't that solved by creating typescript bindings as described in issue #30, along with keeping the codebase ES6/node compliant ? IMHO the codebase doesn't need to be in typescript to have typescript bindings. We get the best from the both worlds. Typescript still doesn't have native currying support and I've seen what must be done to circumvent this. Another disadvantage for this I personally see is that more people can write native javascript than typescript. It may deter some programmers to issue a pull request. I've seen that on coffescript projects. I totally understand using typescript on large codebases, but I don't believe this project will benefit from it.

[KiaraGrouwstra]

Yeah, benefits over .d.ts would just be inference / validation / helping not to forget.
For all I know you're right just the file extension could scare people off, though technically any valid JS is still valid TS.
I can relate on the currying. :(

[char0n]

@tycho01 can you for now own issue #30 ? You're the most complement person on that issue. I would have to dust my ts knowledge. It was more than one year ago I last wrote typescript.

[KiaraGrouwstra]

sure :)

[char0n]

Cool ;]

…

On 27 February 2017 at 10:34, Tycho Grouwstra ***@***.***> wrote: sure :) — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALzBhJmZnOe_tswXYPsMkfxyeTScoHpks5rgpjDgaJpZM4MAgjE> .

-- Vladimír Gorej email: v <gorej@codescale.net>ladimir.gorej@gmail.com tel: +420 777 861 279, +421 948 023 011 web: https://www.linkedin.com/in/vladimirgorej

[char0n]

Todo: isNumber, isNotNumber, isNaN, isNotNan, isFinite, isNotFinite, isInteger, isNotInteger

After implementing these functions, we can close this issue and adding type related functions on operational basis. The plan is to start implementing the functions from the cookbook itself. (Also pick ones that are in rcb and not in cookbook and make sense to have them in ramda adjunct).