Re: Can't use +initialize, now what?
Re: Can't use +initialize, now what?
- Subject: Re: Can't use +initialize, now what?
- From: Saagar Jha <email@hidden>
- Date: Thu, 30 Mar 2017 09:41:32 -0700
+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 <email@hidden> wrote:
>
>
>> On Mar 29, 2017, at 4:24 PM, Charles Srstka <email@hidden> wrote:
>>
>>> On Mar 29, 2017, at 3:41 PM, Greg Parker <email@hidden> wrote:
>>>
>>>> On Mar 29, 2017, at 9:02 AM, Charles Srstka <email@hidden <mailto:email@hidden>> wrote:
>>>>
>>>>> On Mar 29, 2017, at 10:51 AM, Jens Alfke <email@hidden <mailto:email@hidden>> wrote:
>>>>>
>>>>>> On Mar 29, 2017, at 6:57 AM, Daryle Walker <email@hidden <mailto:email@hidden> <mailto:email@hidden <mailto:email@hidden>>> 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 (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
_______________________________________________
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