Going full FP within a UI application or REST application becomes pretty difficult at the framework layer. I think this works great for business logic, but when it comes to persisting states and maintaining data structures, by definition, you cannot go functional because it breaks the first rule of functional. FP written code requires that you have inputs and outputs. Nothing outside of that.
So think about a function isLoggedIn($loggedIn). You'll have to continually pass in $loggedIn everywhere. To write isLoggedIn() functionally, you would need to pass in the state and have the method determine if you were logged in based on the state. Imagine how many places you would need to get the state every time you would want to know if a user is logged in.
So think about a function isLoggedIn($loggedIn). You'll have to continually pass in $loggedIn everywhere. To write isLoggedIn() functionally, you would need to pass in the state and have the method determine if you were logged in based on the state.
Isn't this kind of moot though? I mean, everywhere that you're calling isLoggedIn() you should have access to the state. Right? Is it really worse to call isLoggedIn($user)?
Imagine how many places you would need to get the state every time you would want to know if a user is logged in.
So, OOP architecture wants us to abstract isLoggedIn() away from the rest of the application. That way we don't have to write redundant code like
$user = User::getUser();
isLoggedIn($user)
To me, it is much more efficient for me to go to one place to understand where the user is logged in. Rather than having to resolve a bunch of dependencies before I can know if my user is logged in. Example:
What if the system were setup in a way where the user being logged in needed more data than just the user object. For example, they also needed a cookie and a line in the database that says they are logged in. To keep my isLoggedIn() function in the FP paradigm I would then need to do something like this:
Going full FP within a UI application or REST application becomes pretty difficult at the framework layer. I think this works great for business logic, but when it comes to persisting states and maintaining data structures, by definition, you cannot go functional because it breaks the first rule of functional. FP written code requires that you have inputs and outputs. Nothing outside of that.
So think about a function isLoggedIn($loggedIn). You'll have to continually pass in $loggedIn everywhere. To write isLoggedIn() functionally, you would need to pass in the state and have the method determine if you were logged in based on the state. Imagine how many places you would need to get the state every time you would want to know if a user is logged in.
You lose the abstraction of OOP.
Isn't this kind of moot though? I mean, everywhere that you're calling
isLoggedIn()
you should have access to the state. Right? Is it really worse to callisLoggedIn($user)
?Is this where pipelines come in to play?
So, OOP architecture wants us to abstract isLoggedIn() away from the rest of the application. That way we don't have to write redundant code like
To me, it is much more efficient for me to go to one place to understand where the user is logged in. Rather than having to resolve a bunch of dependencies before I can know if my user is logged in. Example:
What if the system were setup in a way where the user being logged in needed more data than just the user object. For example, they also needed a cookie and a line in the database that says they are logged in. To keep my isLoggedIn() function in the FP paradigm I would then need to do something like this:
Now instead of just getting a user, I need to get the cookie and the db value. ALL just so I can write my functions in the FP paradigm.