• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Private Methods
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


References: 
 >Private Methods (From: Richard Charles <email@hidden>)
 >Re: Private Methods (From: Sean McBride <email@hidden>)
 >Re: Private Methods (From: Richard Charles <email@hidden>)
 >Re: Private Methods (From: Jens Alfke <email@hidden>)
 >Re: Private Methods (From: Charles Srstka <email@hidden>)
 >Re: Private Methods (From: Quincey Morris <email@hidden>)
 >Re: Private Methods (From: Charles Srstka <email@hidden>)
 >Re: Private Methods (From: Quincey Morris <email@hidden>)
 >Re: Private Methods (From: Charles Srstka <email@hidden>)
 >Re: Private Methods (From: Quincey Morris <email@hidden>)

  • Prev by Date: Re: Private Methods
  • Next by Date: 3rd party framework crashes with invalid code sign
  • Previous by thread: Re: Private Methods
  • Next by thread: Re: Private Methods
  • Index(es):
    • Date
    • Thread