> On Apr 27, 2016, at 12:39 PM, Vladimir.S <[email protected]> wrote:
>
> IMO very important questions and suggestions.
>
> Firstly, wanted to ask about "required" keyword in your examples - do we
> expect to have it in meaning "implementing the protocol method" ? I'd like to
> have it very much.
I included it to mean “implementing a required protocol method”, providing a
compile-time check that specifically addresses the same kind of issue as “near
miss” detection.
> * About the "override" keyword : +1 from me. We should be clear and explicit
> if we override method from default protocol implementation.
> Right now (as I understand) we have some mess when class and protocol has the
> same methods. For example :
>
> protocol A {}
>
> extension A {
> func y() {print("Y in A")}
> }
>
> class C:A {
> func y() {
> print("Y in C")
> }
> }
>
> var c : A = C()
> c.y() // what do you expect? "Y in A" is here. I expected "Y in C”
overriding a defaulted method without specific clarity of intent should raise a
compiler warning. It is a likely spot where a developer may have acted without
meaning to. Mandating override introduces another level of safety.
> Related topic 1&2 : IMO as soon as we have implementation in our protocols,
> and in this case they are 'like' classes, we need to be able to deal with
> these default methods implemented in protocols.
>
> I.e. my point is if we allow protocols to be 'like' classes (to have
> implementations in methods), we need the tools(override,super.xxx) 'like' we
> have when inherit one class from another.
>
> On 27.04.2016 20:10, Erica Sadun via swift-evolution wrote:
>> From the Swift Programming Language: /Methods on a subclass that override
>> the superclass’s implementation are marked with override—overriding a
>> method by accident, without override, is detected by the compiler as an
>> error. The compiler also detects methods with override that don’t actually
>> override any method in the superclass./
>>
>> I would like to extend this cautious approach to protocols, forcing the
>> developer to deliberately override an implementation that’s inherited from
>> a protocol extension. This would prevent accidental overrides and force the
>> user to proactively choose to implement a version of a protocol member that
>> already exists in the protocol extension.
>>
>> I envision this as using the same `override` keyword that’s used in class
>> based inheritance but extend it to protocol inheritance:
>>
>> protocol A {
>> func foo()
>> }
>>
>> extension A {
>> func foo() { .. default implementation … }
>> }
>>
>> type B: A {
>>
>> override required func foo () { … overrides implementation … }
>> }
>>
>>
>> I’d also like to bring up two related topics, although they probably should
>> at some point move to their own thread if they have any legs:
>>
>> Related topic 1: How should a consumer handle a situation where two
>> unrelated protocols both require the same member and offer different
>> default implementations. Can they specify which implementation to accept or
>> somehow run both?
>>
>> type B: A, C {
>> override required func foo() { A.foo(); C.foo() }
>> }
>>
>> Related topic 2: How can a consumer “inherit” the behavior of the default
>> implementation (like calling super.foo() in classes) and then extend that
>> behavior further. This is a bit similar to how the initialization chaining
>> works. I’d like to be able to call A.foo() and then add custom follow-on
>> behavior rather than entirely replacing the behavior.
>>
>> type B: A {
>> override required func foo() { A.foo(); … my custom behavior … }
>> }
>>
>> cc’ing in Jordan who suggested a new thread on this and Doug, who has
>> already expressed some objections so I want him to have the opportunity to
>> bring that discussion here.
>>
>> — E
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
