Flip & Reverse Adapter

[00:00:00]
>> Kyle Simpson: Let's look at some other kinds of adapters. Here's one called flip. It will sometimes be the case that you have a function, let's say you have a binary function, and it receives an X and a Y. I don't know what it does, it doesn't matter. It's a function that receives an X and a Y.

[00:00:14]
And there's a bunch of places where that works just fine. But then there's this other place where you need a function that receives them in a different order. You need like yx. For whatever reason you need to be able to provide the arguments in a different order. That's a new shape adaptation, right?

[00:00:31]
And if it's a shape adaptation, then we can make an adapter to do that. And we call that adapter flip. Notice what flip does, it takes in a function, returns back a flipped function, line 2, it lists arg 1 and arg 2 and then it transposes them when it calls the underlying function on line 3.

[00:00:50]
And everything else that's passed, if anything, is passed along untouched, but flip simply flips the first two.
>> Kyle Simpson: By the way, flip is the name that is canonically used in most libraries for exactly this function, it's called flip. Same with unary and binary. Wherever possible, I'm gonna try to use whatever names you'll probably see out in the wild.

[00:01:12]
Not always, but where possible, okay? So you'll find a flip in there, and now you know what that does, and that's like learning about the plus operation in math. Because now you know what that does every time you see flip with an fn passed in, you know that the thing that's being passed back has transposed the two arguments.

[00:01:35]
The job of becoming a functional programmer is getting comfortable with seeing all of these different mathematical pieces and saying, yep, this is the flip, and yep, this is the unarian, yep, this is the binary, and this is the this and this is the that. Seeing those and recognizing those at a glance and using them just like you use one plus one equals two.

[00:01:56]
>> Kyle Simpson: When I make G on line 11, that is the flip of F. So when I pass in G 1, 2, 3, 4, the underlying F actually receives 2, 1, 3, 4, the first two arguments having been transposed. A somewhat less common example that you may find would be reverseArgs.

[00:02:15]
That's a name that I made up, okay? Because this isn't one that you're gonna find in all of your functional programming libraries, but it's one that I've often found useful. So I went and made my own higher order function utility, because sometimes I have an n-ary function, three inputs and I need them all three reverse.

[00:02:36]
Not just the first two flipped, but I need all three of them to go in reverse order. That's happened to me on a number of occasions. So what does reverseArgs do? Exactly what you expect, takes a function and returns back a new function that takes the list of arguments, line 2, and line 3, it reverses them.

[00:02:59]
>> Kyle Simpson: That's an example of an adapter that I made that I might use. Not one you necessarily find but it's an example, when you find yourself messing around with the shape of your functions and they don't fit. Try to figure out number 1, can I change the shape of my function at definition so that it fits better?

[00:03:20]
If not, can I make an adapter that changes the shape? Everywhere that we do this, we're looking for common patterns. The functional programmer is looking for the Lego piece that looks exactly like the Lego piece that they have a big old pile of. I want this thing to look like a Lego piece that I already have.

[00:03:44]
I don't want to go invent new utilities all day every day. Stop and think about that for a moment, because that may not be obvious. Why might I not wanna just invent ad hoc utilities all over the place? Because, quite honestly, it's kind of creative and fun to do so.

[00:04:02]
I can come up with all kinds of different shape changing ones. Why wouldn't that be a good way of approaching my code base? And I would suggest to you that maybe why it's not such a great idea is because the whole point of being able to glance at something is the familiarity, the recognition of it.

[00:04:24]
Wherever possible if the things that we are using are the known common things that every functional programmer for the last 60 something years have used, that's good. But when a functional programmer comes to your code base and they see this thing and they're like, what, never seen that Lego before.

[00:04:42]
It's less familiar, so somebody has to spend more time reasoning about that math. Where it's possible for us to do so, we should try to make it recognizable at a glance. We should try to use the standard common ones. So that means get real familiar with at least one functional program library and most of the methods that it provides.

[00:05:06]
Once you've spent a few hours reading through the documentation for Ramda, for example, you're gonna find yourself looking at a thing, seeing this shape and this shape and sayng, I know what that one's called. I saw that in the Ramda docs.
>> Kyle Simpson: Congratulations, that's functional programming. Instead of go invent your own and make one that isn't consistent and familiar, try to make it fit in with the existing patterns wherever possible.

[00:05:33]
And when you can't, make your own, document them well, put them in a standard library that the whole app uses and use them as much as possible. That way everybody gets familiar with them.