[swift-evolution] [Review] SE-0026 Abstract classes and methods

[Andrey Tarantsov]

> This should be resolved when PwS  <http://article.gmane.org/gmane.comp.lang.swift.evolution/3082>(Protocol with Storage) get alive:
> 
>   // Framework land
>         public protocol DatabaseRecord {
>       internal extension DatabaseRecord {
>                 var referenceRow: DatabaseRow
>        public  extension DatabaseRecord {

Yay for visibility and storage in protocols, and generally for being able to provide a different API to the implementers of the protocol compared to the clients of the protocol.

But.

> So explain to me: if this code worked:
> 
> 	protocol ActivityViewControlling: UIViewController {
> 		func retrieveText() -> String
> 	}
> 	extension ActivityViewControlling {
> 		@IBOutlet var messageLabel: UILabel!
> 		
> 		override func viewWillAppear(animated: Bool) {
> 			super.viewWillAppear(animated)
> 			messageLabel.text = retrieveText()
> 		}
> 	}
> 
> What would you feel was missing compared to this?
> 
> 	abstract class ActivityViewController: UIViewController {
> 		abstract func retrieveText() -> String
> 		
> 		@IBOutlet var messageLabel: UILabel!
> 		
> 		override func viewWillAppear(animated: Bool) {
> 			super.viewWillAppear(animated)
> 			messageLabel.text = retrieveText()
> 		}
> 	}

For all intents and purposes, you made an abstract class here, but calling it a protocol. 

It has advantages:

+ you can achieve multiple inheritance that way
+ ... hm? what else?

and disadvantages:

+ it's still, for all intents and purposes, an abstract class, but for some reason you're now calling it a protocol — THAT'S confusing, if you ask me;  now there's two kinds of protocols, the normal ones and the ones that do magic stuff when you implement them (I personally think those latter thingies should be called mixins)
+ it has additional limitations (I don't think you can call super, which is often very useful)
+ it's a concept that doesn't work or exist, and there's no telling if it'll be a part of Swift 3 or not

I believe we're confusing conceptual and implementation details here. Conceptually, both approaches seem to be using two different names for the same thing; I don't really care if the functionality I need comes through a supercharged protocol or a slightly enhanced class.

Are we really discussing anything more than a name? If yes, what is it?

Implementation-wise, the compiler can always translate abstract classes into protocols internally, so I don't really see the implementation difference as important.

A.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160329/1448646b/attachment.html>