4 ms·
Go interfaces, Rust traits, and Haskell typeclasses and simple parameters do exactly what you ask. In fact, it's harder to mock/stub in OOP than it is in FP by
by ilovecaching 8y ago
Go interfaces, Rust traits, and Haskell typeclasses and simple parameters do exactly what you ask. In fact, it's harder to mock/stub in OOP than it is in FP by the nature of FP making all dependencies always explicit. Being able to use a 'property' in the body of the functions means you're now relying on a side effect that will have to be magically mocked.
In OOP, type signatures tend to lie. Not so true for FP.
- p2t2p 8y agoThe problem with simple parameters is that I need to drag all of my low level stuff through all of the layers of the application. I one was imagining a framework for Closure that would do something like that: - you define a bunch of functions. Some of this functions depend on other of those functions. - for dependent ones you define parameters and tag them somehow - you call this functions without mentioning those tagged parameters - during the startup the framework takes over and does partial application, generating functions with same names but without tagged parameters, so you kinda have your dependencies injected. I don’t know if this sounds too crazy or too incorrect for Closure’s paradigm.
- ilovecaching 8y agoThat's what composite values are for, combining related pieces of data such that they can be threaded through an application as a unit. State in FP is passed this way through an application. Adding a framework is a premature abstraction that is likely a sign that you've got your types wrong.