Naming & Grouping

[00:00:00]
>> Here's a user class. We have a constructor, and we've got first name, last name, makes a full name down there, cool. Job well done. We have a user and it works. We tried a different way. We have a user data type. And we have full name. This time we're using joins, same thing.

[00:00:21]
But down there, works exactly the same as it did before. There's a difference here, we can actually rename this full name here where we join the first and last to join with space, right? Now, let's try to join the firstName and the lastName with a space. And all of the sudden, emerges these properties.

[00:00:47]
If we start to generalize, if we start to try to work with these properties, we end up noticing that joinWithSpace is associative down there. It doesn't matter how I group them. Therefore, I can join as many as I want, and I end up with these roles of composition, which is nice I didn't have that with for full name.

[00:01:10]
In fact in joinWitSpaces, reusable utility now that's not buried and stuck and tied to an object to be rewritten again and again. Or you can take it a step further and say joinWithSpaces, we're going to take any joinable. So we're going to program to the interface joinable. And then we'll pass in an array, which is joinable.

[00:01:32]
But it could be other things, could be a tree, could be objects with keys and values. So we'll pass in a joinable and there we get joinWithSpaces again. And this is the same thing as encapsulation. So the only thing joinWithSpaces can do is called join. It knows nothing else.

[00:01:55]
It gets a joinable it can't decide to look at the object. And if you think back to that user class where we had, let me go back up here, we have the entire user at our disposal and all the other methods. We have this in here. So we can do a lot of stuff.

[00:02:15]
But over here, there's literally one thing we can do, we can call join. And that's it. So it's really just the argument that makes this special. To take it a step further, if we have the identity function, it takes some a and returns it back. There's nothing it can do with that value.

[00:02:35]
It knows nothing about it. It can't call any methods. It can't do anything to it. And so this is how we get encapsulation with functional programming. Does anybody have any questions on that one? Cuz it's a weird concept. The encapsulation is the dual of abstraction and this is kind of the abstraction side of it is that you don't know anything about it.

[00:02:53]
So I can't actually touch it. So therefore I get information on it.
>> What's the value of that function?
>> If we jump into Run dev. So, let's see if I have {Either} = require('types'). Cool, let's first say Either.of(2).fold. Let's go ahead and make identity. And it takes an a, returns an a.

[00:03:26]
I can actually fold out the value by saying I have a function that takes that value and spits it back out at you. Instead of having to write a handler that takes the number two and then returns the number two, that's the same as this, right? I can just call identity.

[00:03:46]
That will come in handy more and more throughout your functional programming career, but it's it's a little weird to see off the bat but eventually it it's a good utility. Yeah, what's up?
>> Would it be fair to say that a lot of things in functional programming rely on the identity mode, but we're as programmers not gonna be putting it to use as frequently as it's used by the structures that we use?

[00:04:14]
>> That's fair to say. We'll actually see that in mono transformers supplying the identity functor to a transformer which recovers the original type. It's a great utility to have and it's founded in theory. We have composition which takes f and g, and we have an identity. And actually, it turns out that those are the two things that you need to define a category, and category theory and they're pervasive.

[00:04:42]
And we'll see some of that in a minute here when we talk about monoids. Identity on functions just takes a value transfer. Let's go to, okay, so we want highly generalized functions. That's not a hard rule. It's just a good guiding principle. To say I'm just going to keep abstracting away until I'm programming to the most minimal interface.

[00:05:12]
Then I get the maximum reuse, and I get information hiding. And if I change my program here there, it's not gonna ripple. So we keep working on these higher highly generalized functions until we hit a nice balance.