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

[Thorsten Seitz]

Am 01.03.2016 um 01:37 schrieb Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org>:

>> https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md
>> 
>>    • What is your evaluation of the proposal?
> 
> -1.
> 
> Swift already has a means to create abstract types; we call them "protocols". Protocols cannot yet do all of the things that abstract classes can. But I think we would be better served by enhancing protocols to fill these gaps, rather than creating a parallel construct which muddies the conceptual simplicity of our current classes.

I'm all for enhancing protocols.


> I believe the missing functionality would include:
> 
> 1. Being able to constrain a protocol so that conforming types must inherit from a particular class.
> 2. Being able to use `override` and `super` in a protocol extension as long as the protocol has a must-inherit requirement ensuring the relevant member exists.

Just a note: This would require naming the concrete super protocol to use, because multiple parents might provide the relevant member (and by virtue of protocol extensions they might even gain this member after the fact of defining the protocol containing the super call). Knowing which super to call is the advantage of and reason for the restriction to single inheritance when deriving from a parent class. 


> 3. Being able to declare stored properties in protocol extensions, as long as they were declared in the same module as the protocol.

That would be nice.


> Three more things would be nice-to-haves:
> 
> 4. Being able to declare conformance only to the protocol in a class, and have the required inheritance be implied.

Sorry, I don't understand that.


> 4. Being able to add static members which could be called on the protocol itself, not just types conforming to it.
> 5. Being able to add factory initializers to the protocol which could initialize any conforming type.

That would be an important requirement as soon as protocols can contain properties.

I'm missing an important feature in your list: being able to declare protocol members with access scopes different from that of the protocol, i.e. private or internal in a public protocol.
This is a very important requirement for something like template methods.

Another important feature quite related to that is a "protected" scope.


> With these six features in place, I believe Corelibs Foundation could implement its class clusters (NSArray et.al.) as protocols constrained to subclass NSObject, and clients of both libraries could be source-compatible.
> 
> I see the following benefits in going with protocols:
> 
> * Draws a bright line between abstract and concrete types.
> * Required language changes are incremental.
> * No problems with private abstract members of public types; all protocol requirements are already as public as the protocol itself.

That is a marked disadvantage which prohibits defining partial behavior which is filled in by concrete types!
If protocols should remain like that then that alone is a decisive argument for adding abstract classes.

-Thorsten 


> * Allows for more flexible application (e.g. `UITextField` can conform to `protocol TextualView: UIView` even though it's actually a grandchild class of `UIView`).
> 
>>    • Is the problem being addressed significant enough to warrant a change to Swift?
> 
> Yes. Just not *this* change.
> 
>>    • Does this proposal fit well with the feel and direction of Swift?
> 
> No, I don't think so. Currently Swift draws a bright line between concrete and abstract types: protocols are abstract and all other types are concrete. Allowing abstract classes would blur this distinction.
> 
>>    • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> 
> I have used abstract classes, but only in languages with an "everything is a class" approach. I always found them clumsy and wished for something better.
> 
> I have also used languages (including Objective-C) with no effective solution to the problem abstract classes attempt to solve other than the equivalent of `fatalError("not implemented")`. That sucked too. I quite agree with the desire to find a solution to this problem.
> 
>>    • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 
> I have read the proposal and all prior reviews, and participated in pre-proposal discussions.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution