> 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