On Aug 18, 2015, at 6:22 PM, Quincey Morris
<[email protected]> wrote:
>
> On Aug 18, 2015, at 15:48 , Charles Srstka <[email protected]
> <mailto:[email protected]>> wrote:
>>
>> If bar() is declared as private instead of internal, the library’s copy of
>> bar gets called each time
>
> The most likely difference resulting from that is that private bar can be
> inferred to be ‘final’, whereas I’m not sure that internal bar gets anything
> inferred (currently) without whole-module optimization turned on.
>
> So maybe the results you're seeing (in the other test, too, perhaps) reflect
> the difference between dynamic dispatch and static call, rather than some
> other (hypothetical) mechanism that keeps method names separate across module
> boundaries.
Nope, I think I’ve figured out what was going on, and it’s much simpler than
either of those things:
Framework code:
public class BaseClass {
public init() {}
public func foo() {
print("Foo called in library")
}
}
App code:
import MyFramework
class DerivedClass: BaseClass {
func bar() {
print("Bar called in app")
}
}
let obj = DerivedClass()
obj.foo()
New framework code:
public class BaseClass {
public init() {}
public func foo() {
print("Foo called in library")
self.definitelyNotBar()
}
internal func definitelyNotBar() {
print("definitelyNotBar called in library")
}
}
Output:
Foo called in library
Bar called in app
Yep, we’ve re-invented the base class problem.
Charles
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
