> On Jan 5, 2016, at 8:29 PM, Greg Parker <gpar...@apple.com> wrote:
>
>>
>> On Jan 5, 2016, at 3:37 PM, Charles Srstka via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>> On Jan 5, 2016, at 11:52 AM, Douglas Gregor <dgre...@apple.com
>>> <mailto:dgre...@apple.com>> wrote:
>>>
>>> There are better mechanisms for this than +load. But one would have to deal
>>> with the dylib loading issue and the need to enumerate root classes to get
>>> to a complete implementation. Frankly, I don’t think this level of
>>> Objective-C runtime hackery is worth the effort, hence my suggestion to
>>> make the existing behavior explicit.
>>
>> Yeah, +load was just to throw together a quick-and-dirty demonstration, and
>> not what you’d actually use. You have a point about libraries and bundles;
>> you’d have to hook into that and rescan each time new code was dynamically
>> loaded. However, the enumeration of classes only seems to take around 0.001
>> seconds, so I don’t think it’s terrible.
>
> Enumeration of classes is terrible: it forces the runtime to perform lots of
> work that it tries very hard to perform lazily otherwise. I would expect your
> measured cost to be much higher if you had linked to more high-level
> libraries (UIKit, MapKit, etc).
That was my gut reaction to the idea also, when I had it, but it seems to run
pretty fast no matter what I do. I just tried dragging every framework from
/System/Library/Frameworks into the project, removing only the Java frameworks,
Kernel.framework, Message.framework, and vecLib.framework. Time taken was
0.004260 seconds.
It is, of course, ugly and hacky as hell, and that might make a pretty good
reason not to do it. :-/ What do you think about the other idea, of adding to
NSObject’s default implementation of +resolveInstanceMethod:? That *would* be
done lazily, and would avoid all the problems involving dynamically loaded code.
Charles
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
