[swift-evolution] [swift-evolution-announce] [Review] SE-0026 Abstract classes and methods
Joseph Lord
Joseph at human-friendly.com
Fri Feb 26 20:38:42 CST 2016
Sent from my phone
> On Feb 26, 2016, at 10:54 PM, Vanderlei Martinelli via swift-evolution <swift-evolution at swift.org> wrote:
>
> We have a hammer and pliers. Now we invented a screwdriver, let's throw the hammer in the trash. (If it was a sonic screwdriver would be cool.)
>
> I believe that each tool is used for a purpose. Taking the possibility of other tools just because there is a new way to another does not seem to make sense.
The path of including everything that is useful leads to C++ and isn't what I want for Swift.
> Otherwise, what about eliminate classes for good? What do you (plural) think? So the Swift will be fully POP. (This remember me: "POP goes my heart!" I can swear I'm listening someone singing this song here.)
If it wasn't for existing code and particularly Cocoa Touch I might be tempted to propose removing implementation inheritance. Even the if that was the case a reference type would still be desirable and probably necessary.
> I like POP anda I like OOP. I'd like to use both in Swift development.
>
> Remembering that Cocoa/CocoaTouch is fundamentally made using classes and subclasses in mind. I know that Objective-C does not have abstract classes, but this is a defect, not a quality.
Yes they are very class based, but they are also heavily protocol and delegation based and I think that is the better pattern to encourage. The only place I can think of where there is an abstract class is in gesture recognition and I think it would be better if there was an additional delegate instead.
> Well... Maybe we have a whole new set of frameworks for OS X/iOS/watchOS/tvOS coming and I do not know?
Existing code will not disappear even if that does happen but that doesn't mean inheritance should be encouraged.
Joseph
More information about the swift-evolution
mailing list