Functional Programming in PHP - PHP Conference Japan 2020

Transcript

1. Functional Programming in PHP
2. Lochemem Bruno Michael • PHP enthusiast from Kampala, Uganda • Functional Programming aficionado • Writes PHP, JavaScript, and some C++ • Recently graduated college • Maintains PHP userland packages and extensions • Authored a book • Loves hoops, movies, and video games
3. Functional Programming, huh? • A declarative programming paradigm • Mandates that pure functions be written • Saliently features the use of expressions • Emphasizes the importance of composition
4. This is not an FP vs OOP debate!
5. What are the benefits? • Functional Programming helps address complexity ◦ Complexity often deters project advancement ◦ Functions exist only as callable units and do not affect histories • FP techniques truncate the cognitive load of developing software ◦ Short-term memory is a finite resource ◦ FP conditions one to parameterize constructs ◦ The paradigm sturdies one’s intellection when writing programs
6. 4-7 Quanta in working memory models
7. All of this in PHP?
8. Expressions
9. First-class functions
10. Do not forget everything you know about programming!
11. Functions everywhere!
12. User-defined functions
13. Anonymous functions
14. Class methods
15. Keep the functions pure, please! Side effects Side causes
16. Not so pure! • Mutable global variable (side-cause) • Value mutated after function is called (side-effect)
17. An improvement? • Use a closure • Mutate only within the function
18. Parameterize the things!
19. Another fix? • Parameterize the accumulator • Return one integer for every $x-$acc parameter combination
20. Every argument input should yield the same output.
21. Referential Transparency • Is a quality of pure functions • Dictates that pure functions calls should be substitutable with their outputs
22. What about classes?
23. OOP has a Forgotten History!
24. What we know • Classes are Composite Data Types • Encapsulation • Property visibility • Inheritance (is-a relationships) • Polymorphism • Setters and Getters What we may not know • Alan Kay’s biological analogy • Immutability in objects • A message-passing API
25. Not pure! • Setter mutates internal state whenever invoked • Each setter call increases temporal coupling
26. The cardinal rule of purity still applies!
27. Either • Remove the setter • Single $empName value for each object
28. Or • Make the setter a pure function • Create new copy of Employee
29. Pure Functions • Do not create side-effects • Yield the same output given the same input • Are referentially transparent
30. Compose the functions! f(x) = x + 1 g(x) = 2x f ∘ g = f(g(x))
31. “If you’re chaining, you’re composing” - From Eric Elliott in Composing Software: An Introduction
32. Traditionally • Invoke functions as function arguments • Cumbersome to deal with long chains
33. Approaching helper library territory!
34. bingo-functional • Suite of FP libraries for PHP and JavaScript • REPL for FP experimentation
35. Point-free? • No explicit parameter mentions • Seemingly more compact
36. const for functions?
37. Some FP sauce to add to your program • Partial application • Currying • Map, Filter, Fold/Reduce • Pattern Matching • Persistent Data Structures
38. You might have used some of these techniques before.
39. Currying • Decompose a function into a series of sub-functions • Each sub-function takes one argument
40. Partial Application • Similar to currying • Also useful for deferred function calls • Each sub-function has variable arity
41. Map, Filter, Fold • Higher-order functions for array transformations • Highly composable • Single iteration for every transformation
42. Pattern Matching • Native support in pure FP languages • Useful whenever data has discernible patterns • Especially good for flow-control • Composable, as a function
43. Immutable Lists • Persistent data structure • Each transformation outputs a new copy • Single iteration for each transformation
44. Real world IO is messy!
45. Messy, huh? Why? • Many operations are inherently impure • Exceptions - used commonly - are also inherently impure • IO can get complicated
46. Impure IO? • Filesystem interaction • Writing to and reading from standard output and standard input • Opening windows • Database interactions
47. Exceptions • Inherently impure • Not good for function chains
48. How you can cope with this • Use functors and monads • Parameterize (might lead to callback hell) • Favor composition with forward function chaining • Use persistent data structures
49. Programming with effects...
50. Functor • Something you can map over • Typically a type class • A type of category • Supports forward chaining
51. Monad • A special type of functor • Convenient because of inherent ad-hoc value • Especially good for flow-control
52. Real world monads • Either and Maybe union types • IO monad • State monad • Reader monad • Writer monad
53. Maybe Monad • Composed of Just and Nothing types • Can evaluate to one of either sub-type at runtime • Useful for error handling
54. Either Monad • Composed of Left and Right types • Allows for more succinct error handling • Great for the Railway pattern
55. IO Monad • Great for I/O-related tasks • Encapsulated within the monad is an executable function
56. State Monad • Stores an initial state • Creates copies of said state; retains both
57. Reader Monad • Useful for sharing data amongst functions • Akin to Dependency Injection (DI) in OO
58. Writer Monad • Great for logging data • Can, in some contexts, be used for event sourcing
59. How do I know I’m doing it right? The functions you write should have the following qualities: • Purity • Referential Transparency • Composability • Conciseness
60. The future looks bright for FP in PHP! • New language features • New RFCs • New libraries • More explanatory material • All-around language consistency
61. My Book Functional Programming in PHP
62. Thank you!