On Mar 29, 2017, at 06:57 , Daryle Walker <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.
So there are actually two distinct cases. One is where the setup needs to be done before the class can be used. In that case, the technique of a lazily-evaluated static can be used instead. The second is where the setup needs to be done before some other setup is done, typically during launching. That used to be done using +initialize on a class that you know is referenced early, and that you can override +initialize in, such as the app delegate. Instead, you can do the setup in didFinishLaunching, usually. If that’s not early enough, you can move it to willFinishLaunching, but you need to be careful about doing UI-related stuff this early, since the application object doesn’t exist yet. If willFinishLaunching is not early enough, then you can put code in your “main” function, but I don’t know how feasible that is in Swift. Incidentally, there have always been other problems with using +initialize. You don’t know how many times it will be called, since it’s called once for each class, and it may be inherited from class to subclass. You have to code defensively against multiple initializations. Also, I don’t think there are any thread safety guarantees, so that’s more defensive coding. Swift’s lazy static initializations are guaranteed to happen once, and to be thread-safe. _______________________________________________ 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
