Re: Private Methods
Re: Private Methods
- Subject: Re: Private Methods
- From: Charles Srstka <email@hidden>
- Date: Tue, 18 Aug 2015 18:39:52 -0500
On Aug 18, 2015, at 6:22 PM, Quincey Morris <email@hidden> wrote:
>
> On Aug 18, 2015, at 15:48 , Charles Srstka <email@hidden <mailto:email@hidden>> 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@hidden)
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:
This email sent to email@hidden