Why Arc Isn't Especially Object-Oriented (2002)

Re:Why Arc Isn't Especially Object-Oriented (2002) by wvenable on Saturday October 20, 2018 @08:14PM (#18266165)

But you don't have an alternative. You subclassed things and someone broke the base class. It happens. But there is no other magic bullet (whether it be all functional programming or something else) that solves that problem. Most just make extension impossible, which isn't really better.

> The "sealed" classes are meant to be semantic boundaries.

The author of the "sealed" class definitely imagined all possible use cases and their code has absolutely no bugs, right?

[ Parent | on HN ]

Re:Why Arc Isn't Especially Object-Oriented (2002) by pdimitar on Sunday October 21, 2018 @11:12AM (#18268381)

> The author of the "sealed" class definitely imagined all possible use cases and their code has absolutely no bugs, right?

...What?

You can compose an instance of the sealed class in yours. You lose all brittleness from inheritance in the process. I've been coding OOP most of my life and I am working with FP for 2 years now -- composition never introduced a bug. Sure it's anecdotal but after a trend repeats itself 5+ times, you start observing patterns and making conclusions.

Additionally, a number of FP languages offer Java-like and Go-like interfaces for an extra peace of mind.

[ Parent | on HN ]

Re:Why Arc Isn't Especially Object-Oriented (2002) by wvenable on Sunday October 21, 2018 @04:04PM (#18269862)

> You can compose an instance of the sealed class in yours.

But I can't subclass a sealed class to fix a bug or add a feature and pass it back into the framework to use. And yes, I have needed to do this otherwise I would never notice it was sealed in the first place.

[ Parent | on HN ]