[Review] SE-0026 Abstract classes and methods

Actually, protocols and extensions cannot handle methods that requires attributes and data storage.

  So, by design, protocols and extensions can only be used to implement stateless interface where abstract classes are true classes with a state supported with attributes and properties.

  Abstract class can also enforce methods to be implemented and avoid misuse of default method implementation.

  For example, NSOperation is a good candidat to abstract class because NSOperation itself is useless as a standalone class and should not be used as-it. -(void)main should be made abstract because I don’t think NSOperation does not have any internal property and has default behavior.

David

···

I am against the proposal. I believe that protocols, mix-ins and composition are better answers to the problems that abstract classes are usually called to solve. In my experience, abstract classes lead to subpar design decisions.

> • Is the problem being addressed significant enough to warrant a change to Swift?

I do not believe so. There are most likely cases where current tools could be improved, by that should be done by improving support for behavior composition rather than forced subclassing

> • Does this proposal fit well with the feel and direction of Swift?

I do not believe so, for the reason outlined above

> • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick glance.

> On 26 Feb 2016, at 19:11, Joe Groff via swift-evolution <swift-evolution at swift.org <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;&gt; wrote:
>
> Hello Swift community,
>
> The review of “Abstract classes and methods” begins now and runs through March 4, 2016. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md <https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md&gt;
> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;
> or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
>
> Proposal link:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md <https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md&gt;
> Reply text
>
> Other replies
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
>
> • What is your evaluation of the proposal?
> • Is the problem being addressed significant enough to warrant a change to Swift?
> • Does this proposal fit well with the feel and direction of Swift?
> • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>
> More information about the Swift evolution process is available at:
>
> https://github.com/apple/swift-evolution/blob/master/process.md <https://github.com/apple/swift-evolution/blob/master/process.md&gt;
> Thank you,
>
> -Joe
> Review Manager
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;
> https://lists.swift.org/mailman/listinfo/swift-evolution

Actually, protocols and extensions cannot handle methods that requires attributes and data storage.

So, by design, protocols and extensions can only be used to implement stateless interface where abstract classes are true classes with a state supported with attributes and properties.

This is true, but maybe that's the problem. A proposal for protocol and extension storage makes more sense to me.

Abstract class can also enforce methods to be implemented and avoid misuse of default method implementation.

Protocols can enforce that methods are implemented. Protocol extensions can avoid misuse of the default method implementation.

For example, NSOperation is a good candidat to abstract class because NSOperation itself is useless as a standalone class and should not be used as-it. -(void)main should be made abstract because I don’t think NSOperation does not have any internal property and has default behavior.

NSBlockOperation (or something like it) can work on its own just fine.

···

On Feb 26, 2016, at 5:21 PM, David Scrève via swift-evolution <swift-evolution@swift.org> wrote:

--
Stephen

  Actually, protocols and extensions cannot handle methods that requires attributes and data storage.

  So, by design, protocols and extensions can only be used to implement stateless interface where abstract classes are true classes with a state supported with attributes and properties.

  Abstract class can also enforce methods to be implemented and avoid misuse of default method implementation.

  For example, NSOperation is a good candidat to abstract class because NSOperation itself is useless as a standalone class and should not be used as-it. -(void)main should be made abstract because I don’t think NSOperation does not have any internal property and has default behavior.

IMHO, NSOperation could be better design using closure. Abstract class is probably a concept that fit well with API that where design with it in mind, but it does not mean it is needed in Swift.

···

Le 26 févr. 2016 à 23:21, David Scrève via swift-evolution <swift-evolution@swift.org> a écrit :

David

I am against the proposal. I believe that protocols, mix-ins and composition are better answers to the problems that abstract classes are usually called to solve. In my experience, abstract classes lead to subpar design decisions.

> • Is the problem being addressed significant enough to warrant a change to Swift?

I do not believe so. There are most likely cases where current tools could be improved, by that should be done by improving support for behavior composition rather than forced subclassing

> • Does this proposal fit well with the feel and direction of Swift?

I do not believe so, for the reason outlined above

> • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick glance.

> On 26 Feb 2016, at 19:11, Joe Groff via swift-evolution <swift-evolution at swift.org <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;&gt; wrote:
>
> Hello Swift community,
>
> The review of “Abstract classes and methods” begins now and runs through March 4, 2016. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md <https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md&gt;
> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;
> or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
>
> Proposal link:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md <https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md&gt;
> Reply text
>
> Other replies
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
>
> • What is your evaluation of the proposal?
> • Is the problem being addressed significant enough to warrant a change to Swift?
> • Does this proposal fit well with the feel and direction of Swift?
> • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>
> More information about the Swift evolution process is available at:
>
> https://github.com/apple/swift-evolution/blob/master/process.md <https://github.com/apple/swift-evolution/blob/master/process.md&gt;
> Thank you,
>
> -Joe
> Review Manager
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

  Actually, protocols and extensions cannot handle methods that requires attributes and data storage.

You don't implement the required code in the protocol/extension you provide a concrete instance conforming to the protocol.

  So, by design, protocols and extensions can only be used to implement stateless interface where abstract classes are true classes with a state supported with attributes and properties.

It is safer to share state only through the specific interface of the protocol.

  Abstract class can also enforce methods to be implemented and avoid misuse of default method implementation.

Require the object conforming to the protocol in the initializer.

  For example, NSOperation is a good candidat to abstract class because NSOperation itself is useless as a standalone class and should not be used as-it. -(void)main should be made abstract because I don’t think NSOperation does not have any internal property and has default behavior.

As mentioned it could just be initialised with a closure (or a simple delegate). With the delegate approach you could still subclass and just return self as the delegate if you really wanted to of some reason.

Joseph

···

On Feb 26, 2016, at 10:21 PM, David Scrève via swift-evolution <swift-evolution@swift.org> wrote: