[swift-evolution] [Review] SE-0026 Abstract classes and methods
Andrey Tarantsov
andrey at tarantsov.com
Tue Mar 29 04:12:01 CDT 2016
I love protocols as much as the next guy, but if the problem I'm solving requires a hierarchy of
RubyInterpreter
SystemRubyInterpreter
HomebrewRubyInterpreter
RVMRubyInterpreter
then thank you, but no, I'll prefer to stick to the most simple and clear solution (an abstract class). Yes, I can turn that into a protocol with extensions, supercharged with some extra features we don't currently have. But why on earth would I want to?
There are no benefits to be had from a protocol here.
Things won't get more clear or readable.
Everyone in the world understands simple hierarchies.
Yes, it's a wrong modeling tool conceptually, but it's a very simple and practical one. Sometimes the problem doesn't call for anything else.
So many people will continue to prefer simple class hierarchies in these cases. Let us be clear about what we're choosing from here.
Our choice is between fatalError("Must override") and a keyword that makes that clear. I'll take a keyword any day, but if you deny me, I'll go on using fatalError.
But please don't live in a fantasy world where, due to lack of SE-0026, I switch to protocols for those very simple and isolated cases, unless you can demonstrate the benefits for those specific cases. Please do not be so high-handed.
A.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160329/2676bfc8/attachment.html>
More information about the swift-evolution
mailing list