Configurable Types in Swift | Hacker News Reader

Configurable Types in Swift

swiftbysundell.com

32 pointsingve7 comments

It's a good article, but it reminds me that sometimes I feel like with protocol-oriented programming we're just reinventing class hierarchies with a new kind of polymorphism and finding a way to do things with composition instead of inheritance, just because that's the new right way to do everything. Other than value types vs reference types, what would be the downside of FileImporter being a base class with a few subclasses for each file type? The base class could have a factory method that returns one of the subclasses.

And could we achieve much of what we want with protocol-oriented programming crossed with value types if structs could have inheritance? I know that sounds strange.

In short, I totally get the elegance of protocol-oriented programming, but I wonder if for most of its applications a traditional class hierarchy would be more than good enough. I'm not sure inheritance is as bad a word as people make it out to be.

> What would be the downside of FileImporter being a base class with a few subclasses for each file type?

This model doesn't support a single class having multiple base classes very well, whereas this is supported very well by the Swift/Rust approach. Base classes typically also allow shared state between base and derived classes, which can make code brittle and difficult to follow.

> This model doesn't support a single class having multiple base classes very well, whereas this is supported very well by the Swift/Rust approach.

Totally agree, but you can have a single base class that adopts multiple protocols or subclasses that adopt multiple protocols. It doesn't have to be an either/or. Inheritance can work together with protocols.

The controversy over inheritance has to do with implementation inheritance, where any method that's defined on a base class can depend on methods that may have been overridden in some derived class, or rely on some non-codified invariants that a derived class might break: this is known as the "fragile base class" problem. By using composition over inheritance, this is not something that can happen by default, because there is no provision for a method call on some "base" method to dispatch on the object's "actual" type, or more broadly to rely on anything but what's defined in the base object itself. You can recover that dispatch-like behavior ("open recursion"), but it's something you have to code yourself and opt into explicitly. This is good for rigor and auditability, as well as just being all-around simpler and easier to understand. Implementation inheritance is too general of a feature, and just not a good abstraction.

I'm very aware of the fragile base class problem. But it's a non-problem for many of the small class hierarchies that protocol-oriented programming examples are often used as examples of replacing. Surely, there would be no fragile base class problem here with a total of 1 base class and 3 subclasses.

If you're doing something like the Swift standard library, protocol-oriented programming is a huge win. If you're doing a small class hierarchy as you would be to do this example, I don't see the big win.

Inheritance is usually bad since extending from a base class puts you at risk for shared and a centralized dependency for your subclass implementations. I would even argue a protocol witness approach here makes more sense than protocol oriented.

I don't understand the issue with the switch statement at the beginning. It's said that it "isn't great from a flexibility point of view" and "is more or less guaranteed to grow out of control".

In the hypothetical example of a note taking app, what bad thing would happen by keeping the switch statement? Adding two lines to a switch statement seems like a trivial step compared to all the other work required to write an importer for something like markdown.

The switch statement is trivially easy to read and understand, more so IMO than replacing it with a FileImportResult enum, a generic FileImporter class, creating static factory methods for each import category, etc. I'd like to understand the benefits of programming in that style over something more simple.

Reply on news.ycombinator.com