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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> 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 >>>>> <[email protected] <mailto:[email protected]>> 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 >>>>>> <[email protected] <mailto:[email protected]>> 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 >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
