OOP Is Dead, Long Live OOP

Re:OOP Is Dead, Long Live OOP by ilovecaching on Thursday October 18, 2018 @05:14PM (#18252192)

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.

[ Parent | on HN ]

Re:OOP Is Dead, Long Live OOP by p2t2p on Thursday October 18, 2018 @06:22PM (#18252692)

The 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.

[ Parent | on HN ]

Re:OOP Is Dead, Long Live OOP by ilovecaching on Thursday October 18, 2018 @06:34PM (#18252797)

That'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.

[ Parent | on HN ]