<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class="">On Jan 5, 2016, at 11:52 AM, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> wrote:<br class=""></blockquote><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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.</span></div></blockquote></div><br class=""><div class="">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.</div><div class=""><br class=""></div><div class="">Although what might be easier would be just to include this in NSObject’s default implementation of +resolveInstanceMethod: (I don’t think you’d need to do it for every root class, since NSObjects are almost always what you’re dealing with in cases where you’d want this, and I don’t think Swift allows you to create non-NSObject @objc classes anymore anyway). This would lazily create the Objective-C selectors as they are needed, so there would be no need for iterating through classes. You could either do this with the disclaimer that the functionality required some OS X 10.x, or if you wanted it to be backward compatible you could always swizzle it in on older OS X versions (or do what KVO does and stick a dynamically-created subclass in NSObject’s place).</div><div class=""><br class=""></div><div class="">The thing that makes it a shame that this doesn’t work currently (and, indeed, crashing the compiler if the function isn’t optional) is that Swift’s protocol-oriented-programming concept is very appealing and could solve a lot of problems, but especially when you’re dealing with UI programming, you’re often working with code that will only take NSObjects. So if your model objects are going into something like a view-based NSTableView, which is pretty awkward to use without using bindings, using composition to build the model classes doesn’t work very well.</div><div class=""><br class=""></div><div class="">Charles</div><div class=""><br class=""></div></body></html>