A agree with John. Imagine
class A {
func foo() -> Int {
return bar()
}
func bar() -> Int {
return 0
}
}
class B {
override foo() -> Int {
return bar() + 1
}
overr func bar() -> Int {
return 32
}
}
What would A(foo) return? Some would say that 0, some that 32...
> On Aug 19, 2016, at 5:14 PM, Félix Cloutier via swift-evolution
> <[email protected]> wrote:
>
> What if two modules declare the same extension method?
>
> Félix
>
>> Le 19 août 2016 à 03:06:23, Brent Royal-Gordon via swift-evolution
>> <[email protected]> a écrit :
>>
>>> On Aug 17, 2016, at 6:57 PM, John McCall via swift-evolution
>>> <[email protected]> wrote:
>>>
>>> Being able to bypass another class's overrides and jump to a specific
>>> superclass implementation on an arbitrary method call is badly
>>> encapsulation-breaking, and I can't think of any OO language with
>>> first-class support for it besides C++.
>>
>> Perl 5 does, although of course its object system is a little
>> bit...different.
>>
>> What these languages have in common is multiple inheritance. Calling a
>> specific superclass's implementation is necessary when you have more than
>> one superclass. Swift doesn't have that problem with superclasses, but it
>> *does* have it with protocol extension members.
>>
>> My suggestion would be to allow you to call a particular protocol
>> extension's implementation with:
>>
>> super(ProtocolName).method()
>>
>> `super(Foo)` would always use the appropriate member on `Foo`, which must be
>> a protocol (not a class name), and must be conformed to by this type (not by
>> a superclass). Unqualified `super` would only be valid in classes and would
>> only permit calls to members of the superclass (including protocols it
>> conforms to). That would permit access to default implementations without
>> permitting encapsulation-breaking shenanigans, while leaving plain `super`'s
>> meaning unambiguous.
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> _______________________________________________
>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
