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

[Boris Wang]

why?

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

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


2016年7月22日星期五，Brandon Knope via swift-evolution <swift-evolution at swift.org
<javascript:_e(%7B%7D,'cvml','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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160723/52062673/attachment.html>