[swift-evolution] [Pitch] separate syntax of class inheritance and protocol conformance

[Christopher Kornher]

-1 

I hope that this does not seem too hash but I think that this would be a gratuitous change and it would not provide any benefit to me. With protocol extensions, the difference between classes and protocols is not that great. As far as I am converted, this change would just complicate the syntax and add visual clutter.

I know that some language must have a similar feature, but I have never seen this feature in any other language and I have not missed it.

I fail to see how knowing if some “parent” of a class is a protocol or a class (and this is only an issue for classes) eliminates the need to actually look at the parent to determine its significance / capabilities.

- Chris


> On Aug 1, 2016, at 2:40 PM, Charlie Monroe via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Aug 1, 2016, at 10:22 PM, Haravikk via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On 1 Aug 2016, at 19:05, Goffredo Marocchi via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>> Sent from my iPhone
>>> 
>>>> On 31 Jul 2016, at 21:19, Sean Alling via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> I disagree with this suggestion.  Both a protocol conformance & class inheritance define behavior conformance.  If anything the protocol is more explicitly shown because the required properties and methods are conformed to within its declaration.
>>> 
>>> Especially in a language without abstract classes, inheritance and protocol conformance have a quite important distinction: protocols are about decoupling concrete implementation from behaviour which is not what inheritance allows or promises.
>> 
>> But is it a big enough case for its own syntax? I've had to work quite hard to break myself of old OOP habits, but I've now gotten pretty good at using protocols with extensions to do much of what I used abstract classes and such for (took a while though).
>> 
>> Even when I do use classes with inheritance, unless it's a very simple type I don't usually define protocol conformance as part of the type declaration, so I know the only thing up there will be inheritance; I put all my protocol conformances into extensions.
>> 
>> Also, I don't think it's that hard to figure out what a type represents, as you can alt-click in Xcode to quickly find out whether a type is a class or a protocol, and of course class inheritance is only possible on classes.
> 
> Xcode (or any other IDE) is not part of the language. Many people here are still forgetting that. Saying that it's not an issue, since Xcode will do this, will highlight that. Github doesn't have an Option-Click. Neither do any other SCM-tools. Try to browse the stdlib on Github using a person seeing the code for the first time.
> 
> Swift is aiming to be cross-platform - any argument that Xcode (or any other IDE) can do something is IMHO irrelevant.
> 
> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160801/2f97c074/attachment.html>