> 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.

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to