R.noop

[mondalaci]

It'd be useful to have a function that doesn't do anything.

R.noop = function() {}; // obviously, noop stands for no operation

Could be used in scenarios like:

(functionArray[selectedItem] || R.noop)();

[raine]

noop was recently discussed in #596

[buzzdecafe]

R.always()

[mondalaci]

@buzzdecafe How did you mean in #596 that noop feels pretty side-effect-y to you? R.always() definitely works in this case but the name is very confusing for the reader. noop suggests the purpose of the code much better in such cases.

[buzzdecafe]

IMO R.always() is abuse, but it solves this problem. I think noop feels side-effect-y because it does not do anything with any input value, and doesn't return any values either. So what is it for?

[mondalaci]

@buzzdecafe It doesn't do anything, hence its name. :) I understand your argument but I still think that a function that doesn't do anything has its place in a functional library like Ramda. A good example scenario is the one I provided on the top of this thread. Even some non-functional libraries like Angular include it - https://docs.angularjs.org/api/ng/function/angular.noop

[buzzdecafe]

I certainly see the utility of noop, I just don't see how it belongs here. IMO ramda should be about evaluating expressions, as opposed to performing operations.

[mondalaci]

Well, I guess I'm out of arguments. For me this comes down to practicality but your reasoning is certainly more nuanced. I can continue to use angular.noop, although R.noop would make more sense and be shorter.

[buzzdecafe]

anyone else have $0.02? @CrossEye ? @davidchambers ? Bueller?

[davidchambers]

I added _.noop to Underscore; I see the value. I agree with @buzzdecafe, though, that it's not in the spirit of Ramda. I'm fine with function() {}: it's very clear. I don't feel strongly about this, so I'll neither promote nor oppose the addition of R.noop.

[CrossEye]

What are its arguments? What does it return? Is it idempotent? Does it mutate input objects?

😄

I also don't feel strongly.

It feels very strange to have a function with no return value inside Ramda. And anyone who wants this can add it easily. We haven't tried to do anything like the extension mechanism that Lo-Dash uses, but it would be trivial for anyone to use Ramda's exposed object as a namespace, I suppose, to add such things as this if they wanted:

R.noop = R.always();

But there are clearly times when it's useful.

I probably would not reject a PR (although perhaps @buzzdecafe would.) But I wouldn't be excited by one.

[buzzdecafe]

if no one wants to fight for it, i'm gonna close it

[despairblue]

I'd like that function since it makes the use case below was easier:

var noop = () => undefined

R.cond(
  [R.eq('Known Error 1'), noop],
  [R.eq('Known Error 2'), noop],
  // something we don't expect and thus want to log
  [R.T, error => error]
)('Known Error 1')

// instead of  

R.cond(
  [R.not(
    R.anyPass([
      R.eq('Known Error 1'),
      R.eq('Known Error 2')
    ])
  ), error => error]
)('Known Error 1')

the noop function would ignore all arguments, return undefined and have no side effects, basically be function(){} or () => undefined

[CrossEye]

There are three questions:

• is the function useful?
• does it fit well with Ramda?
• is it easy to work around not having it?

Clearly it's useful. I use some version of it often.

But I don't think it fits well with Ramda. Ramda is about dealing with values. This would be very much an oddball function in Ramda.

And it's very easy to create, either manually, as you've done in your example, or with Ramda:

var noop = R.always(undefined);

If you want to use ramda's R as a namespace for your own functions, you could do this:

R.noop = R.always(undefined);

I don't have a serious objection to this; it simply doesn't feel like a good fit.

[mondalaci]

I don't think that the "it's easy to create" argument is a valid one. I personally rather don't want to extend libraries in any ways because later on a developer can come along looking up the library reference and (s)he won't find the function that I added, leading to confusion.

[buzzdecafe]

I don't think that the "it's easy to create" argument is a valid one

I don't think that is especially persuasive either. IMO the best arguments are:

1. as above: "IMO ramda should be about evaluating expressions, as opposed to performing operations." (argumentum ab auctoritae maea?)
2. noop is just sugar for always(undefined)

[CrossEye]

I absolutely agree that "ramda should be about evaluating expressions, as opposed to performing operations." (So it's at least argumentum ab auctoritate nostra.)

[despairblue]

Ok, convinced :)

[microcipcip]

@despairblue and anybody getting to this thread...noop is available in Ramda Adjunct

[tommmyy]

... and Ramda-extension for really long time

[microcipcip]

@tommmyy OMG I had no idea about this project, thanks :)