[swift-evolution] [Draft] Allow declaration of abstract functions and properties on classes

[Gwendal Roué]

I concur. Protocols are a new tool that needs fostering, but not at all costs.

As Alex says, there's no `super` with protocols.

Besides, protocols are more complex that classes. As many other threads have shown here, the overloading of protocol methods is a complex topic, which requires a high-level understanding of whether a method declaration should enter a protocol definition, or a protocol extension. Surely the topic will improve, but it is likely to remain complex.

So please educate people using protocols, but don't say it is a universal simple panacea. If Swift is actually and actively a research language, it may not have to be a language only for researchers.

Gwendal

> Le 25 févr. 2016 à 08:04, Alex Hoppen via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> I think there is one major use case that is not covered by your 3rd idea: 
> Protocols and protocol extensions are always the top level in an inheritance hierarchy and the methods implemented in protocol extensions are only used when neither the class conforming to it nor any superclass implements the method. In particular this means that you would not be able override viewDidLoad for classes conforming ActivityViewControlling and start the operation to retrieve the text from there, which – as I understood it – was Evan’s idea.
> Because of the ability to override method’s in superclasses I think that abstract classes are a fundamentally different concept than protocols.
> 
> – Alex
> 
>> On 25 Feb 2016, at 02:27, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> That's one alternative, yes. Others include:
>> 
>> 1. Having a delegate provide the `retrieveText()` method.
>> 
>> 2. Having a closure property implement the `retrieveText()` method.
>> 
>> 3. Declaring a protocol `ActivityViewControlling` that requires `retrieveText()` and adding the other logic in an `extension ActivityViewControlling where Self: UIViewController`.
>> 
>> I think that 1 or 2 are usually the best way to handle something like this, but let's explore 3 for a minute, because that's a place where Swift could probably be improved.
>> 
>> Currently, Swift allows you to constrain a protocol to only class types:
>> 
>>   protocol ActivityViewControlling: class {
>>       func retrieveText() -> String
>>   }
>>   extension ActivityViewControlling where Self: UIViewController {
>>       ...
>>   }
>>   class MyActivityViewController: UIViewController, ActivityViewControlling {
>>       func retrieveText() -> String { ... }
>>   }
>> 
>> But when you do that, Swift permits you to use any class type, which is a bit weird semantically—ActivityViewControlling can be applied to any class, but it's really only meant to be applied to subclasses of UIViewController. An ActivityViewControlling type which isn't a view controller is kind of meaningless.
>> 
>>   // Why can I do this?
>>   class PossibleButUseless: ActivityViewControlling {
>>       func retrieveText() -> String { ... }
>>   }
>> 
>> Suppose instead we allow a protocol to require that the conforming class inherit from another class. We could then omit the `where` clause and possibly even make the inheritance itself implicit in conforming to the protocol:
>> 
>>   protocol ActivityViewControlling: UIViewController {
>>       func retrieveText() -> String
>>   }
>>   extension ActivityViewControlling {
>>       ...
>>   }
>>   class MyActivityViewController: ActivityViewControlling {
>>       func retrieveText() -> String { ... }
>>   }
>> 
>> This would also relieve some of the pressure on us to support class-plus-protocol typed variables. In many of these cases, *all* types conforming to the protocol should be subclasses of a particular class, but there's no way to express that in the type system. Subclass-only protocols would correct that shortcoming.
>> 
>> Subclass-only protocols would cover most, if not all, of the use cases of abstract classes, but I think they would be a less dramatic change to Swift, because protocols are already types which can't be instantiated and impose requirements on their subtypes. I therefore believe they would be a better, more Swift-like approach to the problem abstract classes are trying to solve.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>