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

[Matthew Judge]

Let's say I DON'T have a framework that requires me to supply a subclass of
(class) Foo to do something useful, instead I have a framework that
requires me to have my class conform to (protocol) Foo... my problem with
your "2 things vs 1 thing" argument is that it assumes that the subclassing
has to happen in the first place.

I'm not convinced that using protocols in this way is a better solution
than an abstract class, but as protocols develop the POP argument isn't
necessarily "subclass and conform" it's "conform instead of subclass" - so
1 == 1

I do think that a proper evaluation of abstract classes cannot be done
without examining what Swift would look like with protocols expanded to
fill a similar role (which of the two approaches would add more complexity,
which would be more powerful, etc.)

On Thu, Mar 3, 2016 at 4:26 PM, Evan Maloney <emaloney at gilt.com> wrote:

> > On Mar 3, 2016, at 4:21 PM, Matthew Judge <matthew.judge at gmail.com>
> wrote:
> >
> > 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.
>
> It's the difference between forgetting to do two things and forgetting to
> do just one.
>
> Let's say I have a framework that requires me to supply a subclass of Foo
> to do something useful.
>
> With abstract classes, I just need to subclass Foo, and the compiler tells
> me what implementations I need to provide.
>
> With the protocol-based "solution" being proposed, I need to subclass Foo
> *and* I need to remember to declare conformance to FooProtocol. Then and
> only then can the compiler enforce anything.
>
> 2 != 1
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160304/4a9a9fbe/attachment.html>