[swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Félix Cloutier]

The linker is smart enough to get rid of frameworks that you don't actually use.

Félix

> Le 5 janv. 2016 à 21:55:17, Charles Srstka via swift-evolution <swift-evolution at swift.org> a écrit :
> 
>> On Jan 5, 2016, at 8:29 PM, Greg Parker <gparker at apple.com <mailto:gparker at apple.com>> wrote:
>> 
>>> 
>>> On Jan 5, 2016, at 3:37 PM, Charles Srstka via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>> On Jan 5, 2016, at 11:52 AM, Douglas Gregor <dgregor at apple.com <mailto:dgregor at 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 at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160105/ed07b89a/attachment.html>