> On Mar 29, 2017, at 10:51 AM, Jens Alfke <j...@mooseyard.com> wrote:
> 
>> On Mar 29, 2017, at 6:57 AM, Daryle Walker <dary...@mac.com 
>> <mailto:dary...@mac.com>> wrote:
>> 
>> Sometimes, I see something in Apple’s AppKit/Foundation reference site that 
>> mentions that their technique should be loaded early in the program by 
>> putting it in the class’s “+initiallize” method.
> 
> A +initialize method doesn’t necessarily run early in the program; it runs 
> before the first time a method of that class is called. But that class might 
> not be called until later in the process, or never. So +initialize is useful 
> for setting up state that this specific class will depend on — like 
> initializing static variables — but not for program-wide dependencies.
> 
> There’s a more obscure method +load that _does_ get called when the process 
> starts up (at roughly the same time as C++ static initializer methods.) Its 
> use is discouraged because doing stuff at launch time is bad for 
> responsiveness, and because it’s easy to run into problems with dependencies 
> on other stuff being initialized already, like if your +load method calls 
> something in AppKit that hasn’t been initialized yet because _its_ +load 
> method runs after yours…

+load isn’t exposed to Swift either, so that’s not going to work either. You’re 
going to have to roll your own replacement for +initialize. Here’s how I’ve 
been doing it:

class Foo {
    private static let _classInitializer: Void = {
        // do your initialization here
    }()
    
    init() {
        // all static variables are lazy, so be sure not to forget to put this 
at the top of *all* your designated initializers or it won’t happen
        _ = Foo._classInitializer
    }
}

This will ensure that your initialization code will run the first time an 
object of the class is created, which is similar to what +initialize does (but 
not exact, I know).

>> Now the new Xcode release notes say that “• Swift now warns when an NSObject 
>> subclass attempts to override the initialize class method, because Swift 
>> can't guarantee that the Objective-C method will be called. (28954946)”
> 
> Huh, I haven’t heard of that. And I’m confused by “the Objective-C method” — 
> what’s that? Not the +initialize method being compiled, because that’s in 
> Swift. The superclass method?
> 
> Guess I’ll follow that Radar link and read the bug report myself. Oh, wait. :(

You actually can this time, since Swift’s bug reporter is actually open to the 
public. https://bugs.swift.org/browse/SR-3114 
<https://bugs.swift.org/browse/SR-3114>

Basically, with Whole Module Optimization turned on, +initialize wasn’t getting 
called. Their solution was to just get rid of +initialize.

Charles

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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 arch...@mail-archive.com

Reply via email to