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

[Matthew Judge]

Not necessarily commenting for or against abstract classes, but the
following logic confuses me:

"ONLY an abstract class, ON ITS OWN, can force concrete subclassers to
provide an implementation for a given thing.

Protocols can't do this, because if you forget to declare conformance with
the protocol, the compiler can't enforce anything. This pushes what could
be caught at compile-time to a runtime (potentially crashing) problem."

What is the difference between forgetting to declare conformance to a
protocol and forgetting to subclass an abstract class? An abstract class,
ON ITS OWN, cannot force a class to do anything unless that class declares
itself a subclass of the abstract class.


On Thu, Mar 3, 2016 at 3:39 PM, Evan Maloney via swift-evolution <
swift-evolution at swift.org> wrote:

> - What is your evaluation of the proposal?
>
>
> I could not more strongly support the proposal to add abstract classes,
> functions and properties to Swift.
>
> None of the proposals involving protocols as a solution to this have
> addressed the fundamental issue:
>
> *ONLY* abstract classes ON THEIR OWN allow the compiler to enforce
> providing an implementation for a given function.
>
> For example -- and not picking against the author of this, it's just the
> most recent example to grace my inbox:
>
> I am against the proposal because I feel it goes against the Protocol
> Oriented Programming patterns found in the Swift Standard Library. Current
> protocol functionality can provide a solution for the given example. If a
> protocol property is not implemented, the compiler will not let you
> compile.
>
>
> This does not address the fundamental concern of abstract classes.
>
> Yes, a protocol will force you to provide an implementation. However, a
> protocol *by itself* cannot force the implementor of a class to provide an
> implementation unless that class declares itself in conformance with that
> protocol.
>
> ONLY an abstract class, ON ITS OWN, can force concrete subclassers to
> provide an implementation for a given thing.
>
> Protocols can't do this, because if you forget to declare conformance with
> the protocol, the compiler can't enforce anything. This pushes what could
> be caught at compile-time to a runtime (potentially crashing) problem.
>
> Abstract classes enforce a requirement that a given portion of the class
> hierarchy provide an implementation of X.
>
> • Is the problem being addressed significant enough to warrant a change to
> Swift?
>
>
> Yes.
>
> No, protocols implement this functionality, but with a different syntax.
> There is no lacking or additional functionality this proposal provides.
>
>
> No, protocols *do not implement* this functionality. They provide
> something else, and are orthogonal to the class hierarchy.
>
> • Does this proposal fit well with the feel and direction of Swift?
>
>
> Absolutely. Swift is about safety, about letting the compiler perform
> safety checks. ONLY abstract classes allow the compiler to enforce that an
> implementor of a given subclass has provided an implementation for a given
> function.
>
> Solutions that require the use of protocols can only be checked for
> correctness if the implementor of the subclass in question ALSO declares
> conformance to the protocol.
>
> In other words, a protocol-based solution can only be checked by the
> compiler if the developer does 2 things correctly (declares protocol
> conformance and provides an implementation), whereas abstract classes allow
> the compiler to perform checks as long as the developer does 1 thing
> (subclass a given class).
>
> No. It goes against protocol oriented programming.
>
>
> Swift isn't ONLY about protocol oriented programming. Classes are here for
> a reason, and they should not be relegated to second-class status where
> people refuse to consider class-only functionality just because the concept
> can't be shoehorned into something protocol-related.
>
> Furthermore, this is only for classes, structs are being excluded in this
> case. I feel that with most of the standard library being implemented as
> structs, this is not acceptable.
>
>
> Rather than reject this proposal because "this is only for classes,"
> perhaps recognize that this is only for classes PRECISELY because this type
> of problem--the one that abstract classes addresses--only occurs with a
> class hierarchy.
>
> • If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
>
>
> C++ and have found them EXTREMELY useful. This proposal is in line with
> that.
>
> • How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
>
> I've been following this discussion very closely, and before I realized
> there was already a proposal in the queue for abstract classes, I also
> wrote a similar proposal:
>
> https://gist.github.com/emaloney/d0b5bf7dd831d4f7415c
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160303/f45fd40e/attachment.html>