{"id":9336,"date":"2014-08-18T14:07:17","date_gmt":"2014-08-18T18:07:17","guid":{"rendered":"http:\/\/mjtsai.com\/blog\/?p=9336"},"modified":"2015-12-17T13:06:50","modified_gmt":"2015-12-17T18:06:50","slug":"its-a-coup","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2014\/08\/18\/its-a-coup\/","title":{"rendered":"“It’s a Coup”"},"content":{"rendered":"

I highly recommend the Edge Cases episode Swift Is a Really Good Thing and a Step Back<\/a>. There’s much to like about Swift, but much has been lost as well: instantiating classes by name<\/a>, the ability to write your own Core Data–like framework, message passing<\/a> (contra vtable dispatch), swizzling to work around bugs<\/a> and to add features, proxies\/bridges, and more.<\/p>\r\n

The quote in this post’s title, from Andrew Pontious, refers to the general lack of outrage over the loss of dynamism. In broad strokes, the C++ people have asserted their vision that the future will be static, and the reaction from the Objective-C crowd has been apathy. Apple hasn’t even really tried to make a case for why this U-turn is a good idea, and yet the majority seems to have rolled over and accepted it, anyway.<\/p>\r\n

Since the episode was released, there’s been some good news: Wolf Rentzsch is not leaving Edge Cases<\/a>, as was implied<\/a>. More mixed is the news of the significant changes that Apple has made to Swift in beta 5.<\/p>\r\n

The latest version of The Swift Programming Language<\/a> discusses the new dynamic<\/code> modifier:<\/p>\r\n

Apply this modifier to any member of a class that can be represented by Objective-C. When you mark a member declaration with the dynamic<\/code> modifier, access to that member is always dynamically dispatched using the Objective-C runtime. Access to that member is never inlined or devirtualized by the compiler.\r\n<\/p>

Because declarations marked with the dynamic<\/code> modifier are dispatched using the Objective-C runtime, they’re implicitly marked with the objc<\/code> attribute.<\/p><\/blockquote>\r\n

Previously, there was only the @objc<\/code> attribute, and this made it seem like message passing was deprecated. The only way to get it was via the Objective-C compatibility layer, and the @<\/code> sign emphasized that it was not part of the language proper.<\/p>\r\n

One way to interpret the addition of the dynamic<\/code> modifier, which lacks a @<\/code>, is that Apple plans for message passing to be at least an optional part of Swift going forward. It’s currently implemented<\/em> using the Objective-C runtime, but it’s no longer tied to @objc<\/code>. In a future release, there could be pure Swift classes that use message passing.<\/p>\r\n

However, the other half of this change is that methods in Objective-C classes are no longer dynamic by default.<\/em> The dynamic<\/code> modifier doesn’t actually make things more dynamic; rather, Apple has made everything more static but allowed you to opt out by annotating individual methods. To define an Objective-C method, you used to type just -<\/code>. Now you must type func dynamic<\/code>. This reminds me of how you have to type nonatomic<\/code> on most Objective-C properties because the default<\/a> is usually not what you want.<\/p>\r\n

The latest version of Using Swift with Cocoa and Objective-C<\/a> says:<\/p>\r\n

While the @objc<\/code> attribute exposes your Swift API to the Objective-C runtime, it does not guarantee dynamic dispatch of a property, method, subscript, or initializer. The Swift compiler may still devirtualize or inline member access to optimize the performance of your code, bypassing the Objective-C runtime. When you mark a member declaration with the dynamic<\/code> modifier, access to that member is always dynamically dispatched. Because declarations marked with the dynamic<\/code> modifier are dispatched using the Objective-C runtime, they’re implicitly marked with the @objc<\/code> attribute.\r\n<\/p>

Requiring dynamic dispatch is rarely necessary. However, you must use the dynamic<\/code> modifier when you know that the implementation of an API is replaced at runtime. For example, you can use the method_exchangeImplementations<\/code> function in the Objective-C runtime to swap out the implementation of a method while an app is running. If the Swift compiler inlined the implementation of the method or devirtualized access to it, the new implementation would not be used.<\/p><\/blockquote>\r\n

The good news is that Apple has found a way to speed up Objective-C classes in Swift. Presumably, this only applies to methods that are compiled into the same binary as their callers. My guess is that calls into the Cocoa frameworks cannot be optimized in this way.<\/p>\r\n

The bad news is that, by default, your objects will no longer work with KVO or swizzling. If the designer of a class doesn’t anticipate a reason for a particular method or property to be dynamic, that lack of foresight gets baked in at compile time.<\/p>\r\n

In my view, this is a mistake. It makes sense for dynamism to be the default because the costs are low. Objective-C message dispatch is very fast—famously running on 68030 hardware and of course the original iPhone. And, secondly, the Pareto principle applies: when message passing is<\/em> a bottleneck, most of the gains can be obtained by making just a few hot spots more static (e.g. using IMP<\/code>-caching).<\/p>\r\n

The costs for not using message passing, on the other hand, can be high because they make the code more rigid\/brittle. You cannot retroactively make compiled code more dynamic\/flexible. And yet, since dynamic<\/code> is not the default, the odds are that a lot more methods will be static than need to be. Most of the time, objc_msgSend<\/code> is not why your code is slow, yet Swift acts like it needs to protect you from this.<\/p>\r\n

The common case is that message sending is fast enough and that programmers are not smart enough to predict all the ways their code will be used in the future. So Apple should optimize for that and make dynamic<\/code> the default.<\/p>","protected":false},"excerpt":{"rendered":"

I highly recommend the Edge Cases episode Swift Is a Really Good Thing and a Step Back. There’s much to like about Swift, but much has been lost as well: instantiating classes by name, the ability to write your own Core Data–like framework, message passing (contra vtable dispatch), swizzling to work around bugs and to […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"apple_news_api_created_at":"","apple_news_api_id":"","apple_news_api_modified_at":"","apple_news_api_revision":"","apple_news_api_share_url":"","apple_news_coverimage":0,"apple_news_coverimage_caption":"","apple_news_is_hidden":false,"apple_news_is_paid":false,"apple_news_is_preview":false,"apple_news_is_sponsored":false,"apple_news_maturity_rating":"","apple_news_metadata":"\"\"","apple_news_pullquote":"","apple_news_pullquote_position":"","apple_news_slug":"","apple_news_sections":"\"\"","apple_news_suppress_video_url":false,"apple_news_use_image_component":false,"footnotes":""},"categories":[4],"tags":[46,966,54,760,138,901],"class_list":["post-9336","post","type-post","status-publish","format-standard","hentry","category-programming-category","tag-languagedesign","tag-message-passing","tag-objective-c","tag-objective-c-runtime","tag-optimization","tag-swift-programming-language"],"apple_news_notices":[],"_links":{"self":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/9336","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/comments?post=9336"}],"version-history":[{"count":6,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/9336\/revisions"}],"predecessor-version":[{"id":13146,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/9336\/revisions\/13146"}],"wp:attachment":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/media?parent=9336"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/categories?post=9336"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/tags?post=9336"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}