+1 to this idea as well. This works for cases where stuff like awakeFromNib and didFinishLaunching aren’t available, like plugins.
Saagar Jha > On Mar 30, 2017, at 03:39, Jonathan Hull <jh...@gbis.com> wrote: > > >> On Mar 29, 2017, at 4:24 PM, Charles Srstka <cocoa...@charlessoft.com> wrote: >> >>> On Mar 29, 2017, at 3:41 PM, Greg Parker <gpar...@apple.com> wrote: >>> >>>> On Mar 29, 2017, at 9:02 AM, Charles Srstka <cocoa...@charlessoft.com >>>> <mailto:cocoa...@charlessoft.com>> wrote: >>>> >>>>> On Mar 29, 2017, at 10:51 AM, Jens Alfke <j...@mooseyard.com >>>>> <mailto:j...@mooseyard.com>> wrote: >>>>> >>>>>> On Mar 29, 2017, at 6:57 AM, Daryle Walker <dary...@mac.com >>>>>> <mailto:dary...@mac.com> <mailto:dary...@mac.com >>>>>> <mailto:dary...@mac.com>>> wrote: >>>>>> >>>>>> 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><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. >>> >>> You don't even need WMO. Many arrangements of Swift code can bypass ObjC >>> +initialize. >>> >>> Invocation of +initialize is a feature of objc_msgSend(). Swift code does >>> not always use objc_msgSend() when calling methods: some methods are >>> inlined, some are called via virtual table, some are called directly. None >>> of these paths will provoke +initialize. >>> >>> Changing Swift's generated code to guarantee +initialize would be >>> prohibitively expensive. Imagine an is-initialized check in front of every >>> inlined call. It would be more expensive than +initialize in ObjC because >>> +initialize checking is free once you pay the cost of objc_msgSend(). (The >>> ObjC runtime checks +initialize on uncached dispatch, and never caches >>> anything until +initialize completes. Most dispatches are cached so they >>> pay nothing for +initialize support.) >>> >>> +initialize in Swift isn't safe and is too expensive to make safe, so we're >>> taking it away instead. >> >> I wonder if an equivalent Swift-native feature could be added, something >> like a typeInit block? If the block weren’t there, nothing special would >> happen, and if the block were present, the compiler could basically generate >> the code in the example I gave, but add the static var access to the front >> of every initializer and static/class member. That shouldn’t impact >> performance too much, and wouldn’t impact at all in the case that there’s no >> type initializer. > > I hope so as well. My favorite candidate so far would be a reflection > capability to get a list of all classes/structs/enums adhering to a protocol. > Then you could build your own initializable protocol fairly easily (and can > even build whatever facility you want to guarantee a particular ordering or > timing). The reason, I favor it over a specific method, is that it also > enables a bunch of other cool patterns like extensible factories, and easy > plug-ins. > > > > > > _______________________________________________ > > 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/saagar%40saagarjha.com > > This email sent to saa...@saagarjha.com _______________________________________________ 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
