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

[Vanderlei Martinelli]

@Goffredo: +1 for all you said. Well said. :-)

-Van

On Mon, Feb 29, 2016 at 3:00 PM, Goffredo Marocchi via swift-evolution <
swift-evolution at swift.org> wrote:

> I think that the current approach of wishing protocols could basically do
> everything might be adding too much responsibility and complexity to the
> POP pattern, but I think both inheritance and protocol oriented programming
> should receive equal care at this point. Better access control for
> properties and methods as well as abstract classes are a way to improve
> inheritance/OOP that is sorely needed and we should discuss improvements to
> protocol in their own context... without snide remarks on how improvements
> there actually negate a feature somewhere else.
> I think we need to move forward from the OOP vs POP debate, I do think
> Swift can support and evolve both approaches...
>
> Sent from my iPhone
>
> On 29 Feb 2016, at 16:47, Evan Maloney via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> >> You can write class-only protocols in Swift.
> >
> > I do understand that. I'm just saying that if we're considering abstract
> class functionality, it would make sense to host that functionality within
> classes and not have it housed within protocols which work with
> non-inheritable types like structs and enums.
> >
> > The latter would need to needless conceptual leakage.
> >
> >
> >> 2016/02/29 11:27、Evan Maloney via swift-evolution <
> swift-evolution at swift.org> のメッセージ:
> >>
> >>>> I would still rather have a solution that extends protocols than one
> that relies specifically on classes, it seems to me that doing so would
> make the resulting functionality more generic (for instance, it might be
> possible to use it with structs as well as classes). However, I’m starting
> to agree that this is an important language feature indeed, since I can’t
> think of any better (or even equivalent) way of solving the example you
> showed.
> >>>
> >>> I'm not sure I understand the desire to make protocols fulfill the
> role of an abstract class. They're entirely orthogonal concepts.
> >>>
> >>> Protocols are designed to work just as well with structs, enums or
> classes. Of those, structs and enums have no concept of an inheritance
> hierarchy. So, the concept of an abstract class is only relevant in one of
> the three places where a protocol might be used.
> >>>
> >>> It seems to me it would make sense to limit the 'abstract' concept to
> just classes, and not have the concept leak through to other things where
> is may not be relevant (i.e. protocols) and where it definitely wouldn't be
> relevant (structs and enums).
> >>> _______________________________________________
> >>> swift-evolution mailing list
> >>> swift-evolution at swift.org
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> 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/20160229/14166562/attachment.html>