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

Xiaodi Wu xiaodi.wu at gmail.com
Fri Jul 22 18:27:16 CDT 2016


On Fri, Jul 22, 2016 at 6:23 PM, Boris Wang via swift-evolution <
swift-evolution at swift.org> wrote:

> why?
>
> I think it's just because subclass, protocol are different design patterns
> .


If you are doing the designing, you already know this information;
moreover, you're required to use `override` and other keywords to indicate
your awareness. If you are not doing the designing, you cannot understand
the design without knowing more about the protocol or base class in
question than just the fact that it is a protocol or base class. So in
either case, putting this information where it is being proposed is not
*useful*.


> same question:
>     why we need man toilet and women toilet?
>     it's culture ,it's civilization
>

You may not be aware of this, but gender-neutral toilets are increasingly
common in certain parts of civilization :)


> 2016年7月22日星期五,Brandon Knope via swift-evolution <swift-evolution at swift.org>
> 写道:
>
>> I guess my question comes down to this:
>>
>> Is this a change for consistency OR is there actually a tangible benefit?
>>
>> If it's a protocol: you know some methods are being implemented.
>> If it's a base class: it's possible that some methods are overridden
>>
>> Between knowing these two things, what does the distinction *actually*
>> bring about?
>>
>> It's very possible I am not explaining myself properly.
>>
>> Another way: so now you know it is most definitely a base class and not a
>> protocol, what does this information allow you to do differently?
>>
>> Basically, I am for introducing an "implements" or some new syntax for
>> this distinction, but I just want to know if this change is just for
>> consistency to separate inheritance and conformance OR if there is truly a
>> benefit to knowing this distinction.
>>
>> I think this is important to convince people to make a change like this.
>> I understand the idea behind it but the important question is: why?
>>
>> Thanks,
>> Brandon
>>
>> > On Jul 22, 2016, at 10:52 AM, Vladimir.S <svabox at gmail.com> wrote:
>> >
>> > I don't understand the question, really. I need to know because I need
>> to know :-)
>> > I.e. I see new code, I'm trying to understand the structure of the
>> class, its dependency, if all the base code of this class is inside this
>> class or there is some 'base' code that is overriden, etc.. Class and
>> Protocol two different entities with their specifics, so I need to know how
>> the class is composed, if some methods without `override` keyword could be
>> required by protocol..
>> > All the basic things you need to know about the new class you found in
>> some code. No?
>> >
>> > Can I live with current syntax? Yes. Will change make a code more
>> understandable for viewer in area of inheritance/conformance - Yes,
>> especially if you need to review the code not in XCode/IDE but in some
>> other viewer/web page. Should we make this change? I believe yes, but
>> probably I'm not right in my opinion, so we discussing it here.
>> >
>> >> On 22.07.2016 17:32, Brandon Knope wrote:
>> >> I understand.
>> >>
>> >> But why would you need to know if it's a class or a protocol to use the
>> >> type? What understanding comes from knowing this information?
>> >>
>> >> I am honestly trying to understand the problem here and it feels like
>> I'm
>> >> overlooking something.
>> >>
>> >> Brandon
>> >>
>> >> On Jul 22, 2016, at 10:12 AM, Charlie Monroe <
>> charlie at charliemonroe.net
>> >> <mailto:charlie at charliemonroe.net>> wrote:
>> >>
>> >>> Coming to someone elses code, it adds an extra effort to understand
>> the
>> >>> declaration. Putting inheritance and conformance separately makes the
>> >>> declaration easier to read. At least for me.
>> >>>
>> >>>> On Jul 22, 2016, at 4:05 PM, Brandon Knope <bknope at me.com
>> >>>> <mailto:bknope at me.com>> wrote:
>> >>>>
>> >>>> Honest question: what is actually confusing about the current
>> behavior?
>> >>>>
>> >>>> I.E. What is important about knowing whether "DataSource" is a class
>> or
>> >>>> a protocol?
>> >>>>
>> >>>> I thought the blurred distinction was intentional?
>> >>>>
>> >>>> Brandon
>> >>>>
>> >>>>> On Jul 22, 2016, at 9:47 AM, Charlie Monroe via swift-evolution
>> >>>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>> wrote:
>> >>>>>
>> >>>>> I agree that this is an issue. Mostly nowadays when more and more
>> >>>>> classes in Swift do not have a superclass - it simply looks weird:
>> >>>>>
>> >>>>> class MyClass: DataSource
>> >>>>>
>> >>>>> One doesn't know whether "DataSource" is a class, protocol, etc.
>> >>>>> Nevertheless, I do not feel that :: is the answer. I really liked,
>> how
>> >>>>> ObjC did it (which isn't possible with the generics now - is it?),
>> but
>> >>>>> what about something like this?
>> >>>>>
>> >>>>> class BaseClass [SomeDelegate, OtherDelegate, ProtocolX]
>> >>>>> class MyClass: BaseClass [SomeDelegate, OtherDelegate, ProtocolX]
>> >>>>> extension MyClass [OtherProtocol]
>> >>>>>
>> >>>>>
>> >>>>>> On Jul 22, 2016, at 3:14 PM, Vladimir.S via swift-evolution
>> >>>>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>> wrote:
>> >>>>>>
>> >>>>>> I remember that this was discussed, but can't find any decision
>> >>>>>> regarding this.. So, as a last chance, don't we want in Swift 3.0,
>> as
>> >>>>>> big source breaking change, separate class inheritance and protocol
>> >>>>>> conformance in syntax?
>> >>>>>>
>> >>>>>> Sorry if there was a decision about this suggestions. Please let
>> know
>> >>>>>> in this case.
>> >>>>>>
>> >>>>>> I.e. when I see the following I can't understand if the class
>> inherits
>> >>>>>> from base class and conforms to protocols or just conforms to two
>> >>>>>> protocols:
>> >>>>>>
>> >>>>>> class MyClass : First, Second, Third {
>> >>>>>> }
>> >>>>>>
>> >>>>>> We don't have a rule to name protocols with 'Protocol'/other
>> >>>>>> suffix/prefix, or classes with 'T'/'C' prefix or something like
>> this,
>> >>>>>> so I believe to improve the clarity of code we should separate in
>> >>>>>> syntax inheritance and conformance.
>> >>>>>>
>> >>>>>> As I understand we should discuss changes in these areas:
>> >>>>>>
>> >>>>>> 1. class inheritance :
>> >>>>>> class Child: BaseClass
>> >>>>>>
>> >>>>>> 2. class conformance :
>> >>>>>> class Child: SomeProtocol1, SomeProtocol2
>> >>>>>>
>> >>>>>> 3. class inheritance + conformance :
>> >>>>>> class Child: BaseClass, SomeProtocol1, SomeProtocol2
>> >>>>>>
>> >>>>>> 4. protocol conformance for structs:
>> >>>>>> struct Struct: SomeProtocol1, SomeProtocol2
>> >>>>>>
>> >>>>>> 5. protocol inheritance:
>> >>>>>> protocol Child: BaseProtocol1, BaseProtocol2
>> >>>>>>
>> >>>>>>
>> >>>>>> My suggestions:
>> >>>>>>
>> >>>>>> I) separate inheritance with double colon :
>> >>>>>>
>> >>>>>> 1. class inheritance :
>> >>>>>> class Child:: BaseClass
>> >>>>>>
>> >>>>>> 2. class conformance :
>> >>>>>> class Child: SomeProtocol1, SomeProtocol2
>> >>>>>>
>> >>>>>> 3. class inheritance + conformance :
>> >>>>>> class Child:: BaseClass : SomeProtocol1, SomeProtocol2
>> >>>>>>
>> >>>>>> 4. protocol conformance for structs:
>> >>>>>> struct Struct: SomeProtocol1, SomeProtocol2
>> >>>>>>
>> >>>>>> 5. protocol inheritance:
>> >>>>>> protocol Child:: BaseProtocol1, BaseProtocol2
>> >>>>>>
>> >>>>>>
>> >>>>>> II) in class definition use parenthesis to separate inheritance and
>> >>>>>> conformance :
>> >>>>>>
>> >>>>>> 1. class inheritance :
>> >>>>>> class Child: BaseClass
>> >>>>>>
>> >>>>>> 2. class conformance :
>> >>>>>> class Child: (SomeProtocol1, SomeProtocol2)
>> >>>>>>
>> >>>>>> 3. class inheritance + conformance :
>> >>>>>> class Child: BaseClass (SomeProtocol1, SomeProtocol2)
>> >>>>>>
>> >>>>>> 4. protocol conformance for structs:
>> >>>>>> struct Struct: SomeProtocol1, SomeProtocol2
>> >>>>>> or
>> >>>>>> struct Struct: (SomeProtocol1, SomeProtocol2)
>> >>>>>> should be discussed
>> >>>>>>
>> >>>>>> 5. protocol inheritance:
>> >>>>>> protocol Child: BaseProtocol1, BaseProtocol2
>> >>>>>>
>> >>>>>>
>> >>>>>> III) special word like 'conforms'
>> >>>>>>
>> >>>>>> 1. class inheritance :
>> >>>>>> class Child: BaseClass
>> >>>>>>
>> >>>>>> 2. class conformance :
>> >>>>>> class Child: conforms SomeProtocol1, SomeProtocol2
>> >>>>>> or
>> >>>>>> class Child conforms SomeProtocol1, SomeProtocol2
>> >>>>>>
>> >>>>>> 3. class inheritance + conformance :
>> >>>>>> class Child: BaseClass conforms SomeProtocol1, SomeProtocol2
>> >>>>>>
>> >>>>>> 4. protocol conformance for structs:
>> >>>>>> struct Struct: conforms SomeProtocol1, SomeProtocol2
>> >>>>>> or
>> >>>>>> struct Struct conforms SomeProtocol1, SomeProtocol2
>> >>>>>>
>> >>>>>> 5. protocol inheritance:
>> >>>>>> protocol Child: BaseProtocol1, BaseProtocol2
>> >>>>>>
>> >>>>>>
>> >>>>>> Thoughts?
>> >>>>>> _______________________________________________
>> >>>>>> swift-evolution mailing list
>> >>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> >>>>>> 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
>> >>>
>> _______________________________________________
>> 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/20160722/189f43fd/attachment.html>


More information about the swift-evolution mailing list