[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