[swift-evolution] Calling a Specific Implementation

[Charlie Monroe]

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 <swift-evolution at swift.org> 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 <swift-evolution at swift.org> a écrit :
>> 
>>> On Aug 17, 2016, at 6:57 PM, John McCall via swift-evolution <swift-evolution at swift.org> 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
>> 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