4 ms·
> In OOP world it's nearly impossible because of how complicated object protocols are, so if you have objects from different libraries, you'll most likely need
by al_mandi 4y ago
> In OOP world it's nearly impossible because of how complicated object protocols are, so if you have objects from different libraries, you'll most likely need to write lots and lots of facades.
That's not a direct result of OOP. Languages can have extension functions or type classes or delegation to address this. And it's not like the problem magically goes away for procedural code.
- ernst_klim 4y ago> That's not a direct result of OOP. It's actually the core definition of objects. Objects are entities supporting open recursion, self-polymorphism and late binding. There is a difference between "having type-classes" and "having object as a core formalism of computation" > Languages can have Languages can have objects, or actors, or other entities alike. This doesn't mean it's prudent to design your code around the idea of message-exchanging FSMs. Sometimes at some scale objects or actors are useful. > And it's not like the problem magically goes away for procedural code. This is empirically not true, and the frameworks example is the best proof of it. In languages like (functional) Scala, Go, OCaml, libraries do compose well enough, and gluing them is cheap. Any hardcore OOP language eventually brings frameworks like Spring, Rails, etc, because gluing objects is expensive, and for no reason, if functional/procedural alternative is so much cheaper. Even natural transformations between monads are very cheap compared to objects' composition.