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

[Evan Maloney]

> Why is it so important that this feature be expressed strictly within the class hierarchy? 

Because it's a widely-understood concept within programming that I'd venture most Swift developers already know.

> I don't understand why you and the other abstract class supporters don't feel the same way—why you seem to treat this like a fight for your lives, not like a fight for the modestly superior design.

For those of us who support abstract classes, it's quite literally a fight for the life of SE-0026.

That's the proposal we're discussing.

The choice before us now isn't "a solution involving protocols" versus "a solution involving abstract classes", the choice is between abstract classes or nothing.

It's an up-or-down vote on abstract classes.

So you'll have to forgive the adherents for being a bit animated about it. ;)

> 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()
> 		}
> 	}

Per se, I have no objections to your notation. When a specific proposal comes up for a vote, I might support it. So far I am intrigued.

But there's an awful lot that would have to change about Swift protocols in order to get the idea above to work, and that's assuming you could get the community to support it.

Pretty much everything related to protocols and static dispatch would need to be reconsidered in a proposal: for example, what's the order of execution when you have multiple viewWillAppear() overrides in several protocol extensions?

Such a proposal will require a lot thoughtful, careful design. Meanwhile, abstract classes are well-known concept with a well-understood design and well-defined behavior.

The abstract class proposal before us now, on the other hand, is much more limited in scope.

> 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()
> 		}
> 	}


The abstract class concept is quite common in computing, and therefore--for a lot of people--just seeing the 'abstract' keyword conveys all that's needed.

Your notation, on the other hand:

> protocol ActivityViewControlling: UIViewController


Did you just declare a protocol ActivityViewControlling that extends another protocol called UIViewController? Or did you somehow restrict the ActivityViewControlling protocol to only being used with the UIViewController class? What is being stated in your notation is not obvious to me at first glance.

Finally, I don't think your idea necessarily obviates the need for abstract classes. There doesn't have to be Just One Way to achieve something in Swift. I don't think the proposal for abstract classes needs to be torpedoed in order to build support for your proposal.