When can we pass an unwrapped function as a parameter

Question

In Javascript and many other programming languages we may pass functions as parameters to other functions. This is a common practice in functional programming.

We know that a wrapper is required to put a breakpoint there, to see its place in a stacktrace, to have better control of the parameters or to add logic before/after the call.

Are there other objective reasons not to pass an unwrapped function as a parameter?

myFunction1(x => myFunction2(x)) // wrapped
myFunction1(myFunction2) // unwrapped

Answer 1

Asking "should" you use one technique or another is mostly off-limits in SO.

I'm going to answer a related question, though, of when you can and cannot use the technique and what (dis-)advantages there may be.

You can always write foo (x => bar (x)). You can't always write foo (bar). An example of why can be found in another Q & A. A common example of this from my experience is a recursive function with a second parameter which is defaulted in the initial call and passed on subsequent ones. Such a function cannot be successfully passed by simple reference to map, because map supplies additional parameters besides the expected value.

But that's the unusual case. If your function has no default parameters, there seem little use in the wrapper. One argument is simply that if you're going to replace foo (bar) with foo (x => bar (x)), why shouldn't you take it one step further and use foo (y => (x => bar (x)) (y)) or foo (z => (y => (x => bar (x)) (y)) (z)).

The wrappers work, but add nothing... except, as you point out as a place to hang a breakpoint.

This could be a legitimate case for you. I don't spend much time in debuggers these days, but when I do, I might occasionally temporarily add such a wrapper. But I remove them afterward. I find that clean code is of high importance, and unnecessary wrappers simply clutter things up. In code reviews, I run constantly against this pattern:

const foo = (...args) => {
    // do something with args
    return new Promise ((resolve, reject) => {
        bar (something).then(
            (a) => {
                resolve (a);
             }, (err) => {
                reject (err);
             }
        );
    });
}

Which I always need to point out can be much more cleanly written as:

const foo = (...args) => {
    // do something with args
    return new Promise ((resolve, reject) => {
        bar (something) .then (resolve, reject);
    });
}

Then I have to point out further that even this can be better written as

const foo = (...args) => {
    // do something with args
    return bar (something);
}

The point is that the function wrappers around resolve and reject are just clutter. So is the Promise wrapper around bar. It doesn't hurt the outcome, has only a minor impact on performance, but it offers little to balance out the clutter.

(And look, I tried to avoid opinion here, but really couldn't.)

Answer 2

You don't need to wrap a function with an anonymous function to assign it as event handler. If the function should get the event object, this is fine.

window.addEventListener('click', myFunction)

In addition, wrapping the function with an anonymous function would prevent you from removing the event handler, because remove expects the same event handler that was added.

This will work:

window. removeEventListener('click', myFunction)

This will not:

window.removeEventListener('click', e => myFunction(e))

If you need to pass more parameters to to event handler, you'll need to curry it, and assign the returned function to a variable, so you can remove the handler:

const createEventHandler = param => e => {}

const eventHandler = createEventHandler(true)

window.addEventListener('click', eventHandler)
// ...
window.removeEventListener('click', eventHandler)

Answer 3

call(e => foo(e))

is exactly the same as:

call(foo)

with just one level of unnecessary indirection ;)

This has nothing to do with functional programming or currying and I can't see how it can hinder your debugging experience.

You would typically wrap when you want to lock some parameters or the signatures are incompatible. e.g.,

call(a => foo(5, a))

But in cases like this, you may want to consider currying.