Blog post 原文 https://uranusjr.com/blog/post/57/swift-is-objective-c-without-the-c-period/ 苹果在美国时间周一发表了新的程式语言 Swift，然後 Internet 就高潮了，突然冒 出一堆键盘语言专家（包括我自己）争先恐後发表自己的看法。或许因为每个人都有 自己不同的背景，而且 Objective-C 本身也不是很多人特别熟悉的语言，所以看法似 乎颇为分歧，甚至连原以已经在 OS X/iOS 界的工程师似乎也不是完全理解。这里是 一些我自己的想法，其中不少是针对我觉得大家对於 Swift、Objective-C、甚至苹果 本身的误解。 该从哪里开始呢？嗯… SWIFT 是编译语言，但这不代表他不如你最喜欢的脚本语言 没错，Swift 有独立的编译器，而且需要被编译才能执行。但这不代表他比不上那个 脚本语言（请自行对号入座）。毕竟不管怎麽说，绝大多数脚本语言的主流实作都会 在 runtime 时及时将源码编译为 bytecode 才交由直译器执行，而 Swift 的编译器 基於 LLVM（如同近期大多数的语言），与一般脚本语言在实务上的差异其实只有编译 是否自动而已。 不论你打算将 Swift 用於 iOS 或 OS X apps（目前除了这些大概 Swift 也没什麽其 他用途），都需要对你的最终成品进行额外处理，例如打包、key signing（除非你不 上 App Store）等等。苹果在这部分的手续超级繁杂，一般而言都需要 IDE 辅助。既 然有 IDE 存在，编译这件事情造成的 overhead 其实很小。如果你看了 WWDC 展示的 Swift Playground，它及时反应源码修改的能力其实和直译器的差距没那麽大。既然 这个步骤本身对开发流程影响不大，它就是加分了。编译还是能带来很多好处；以 Swift 而言，除了可以进行语法检查之外，还可以带来许多最佳化（尤其 Swift 使用 静态型别）。以苹果的定位，Swift 必须被用在效能吃重的场合，所以这很重要。 编译本身不是罪，苹果只是选择了适合 Swift 用途的路。但这只是实作。当然 Swift 目前看来似乎是 proprietary language，所以这个实作就是一切；不过就语言本身而 言，编译与否仍然不是很重要。但语言本身嘛… SWIFT 应该没有大量借监你想的那个语言 Swift 本身有不少有趣的特点，让许多人开始讨论它究竟从什麽语言借ㄔㄠ监ㄒㄧˊ 了什麽概念。包括 Rust 的原设计者都有些想法。但这些想法还是有点偏差，甚至一 部份根本是错的。 很明显因为对程式语言历史毫无概念产生的错误（Generics 源自 C#？别闹了吧。） 就跳过，多数误解似乎还是源自於很多人（即使 Objective-C programmers）其实不 特别熟 Objective-C。可能是一厢情愿，不过我认为如果想理解 Swift 风格背後的 理由，必须先理解 Objective-C。 从 OBJECTIVE-C 物件到 SWIFT 物件 在 Swift 中，几乎所有的 object instances 都是以 reference 参照。没有指标。 这其实应该就是延续 Objective-C 的做法而已。所有的 Objective-C 物件都必须在 heap 上被 allocated，在程式码中永远是以指标参照： // aString 指向一个在 heap 上被建立，形态是 NSString 的物件实例。 NSString *aString = [[NSString alloc] init]; 这在 Swift 里就直接对应到物件参考： // aString 指向一个（应该也是）在 heap 上被建立的 String 物件实例。 let aString = String() 当然，Objective-C 本身偶尔也会用到 pointer to a pointer。但通常是用来回传多 个值，或者作为 error-handling 的手段。Swift 可以把变数组成 tuple 轻松回传多 个值，所以这种需求其实不大。在真的有必要时，也有 inout 参数可以用。 由於 Objective-C 物件永远是用指标参照，所以 nil（空指标）就被用来代表物件不 存在。推到 Swift 上就是 optionals 了。当然语法本身肯定是有借ㄔㄠ监ㄒㄧˊ别 人，不过概念上还是很必然。 前面说「几乎」所有的 Swift 变数都是物件参考。例外就是 struct。这或许受到 C# 的用法影响，不过无论如何都很明显源自 C 的 structure。Objective-C 在很多地方 使用 struct 描述 POD，所以它有专属的 type 或许也很合理。 顺带一提，虽然文件好像都没有特别提，不过我个人猜测 Swift 的 error-handling 应该还是和 Objective-C 一样基於 return codes 和 error messages。由於使用同 样的 runtime（据苹果说），Swift 的 exceptions 应该也和 Objective-C 类似， 可能得避免使用。 参数冠名（ARGUMENT NAMES）延续了 OBJECTIVE-C 的 METHOD 语法 Objective-C 的 method 语法非常特殊，喜欢的人很爱，讨厌的人也很多。在 Objective-C 中，method 被呼叫时，signature 本身和传入参数会互相交织。例如 如果有个发送 email 的 method，可能就会长成这样： // 送出一封标题为 "Hello"，内容为 "This is a test message." 的信件。 // 寄件人为 me，收件人为 user1 与 user2。 [mailSender sendMailWithTitle:@"Hello" content:@"This is a test message." from:me to:@[user1, user2]]; 第一眼看上去可能很怪，但可读性却非常高。在 Swift 中，同样作用的 method 可 能会这样宣告： func sendMail(title: String, content: String, from: User, to: User[]) { // 实作… } 然後这样用： sendMail("Hello", "This is a test message.", me, [user1, user2]) 这和大多数程式语言的语法相符，但 Objective-C programmers 应该会觉得可读性 变差了。如果使用 parameter names，就可以这样写： func sendMailWithTitle( title: String, content: String, from: User, to: User[]) { // 实作… } 然後 sendMailWithTitle("Hello", content:"This is a test message.", from:me, to:[user1, user2]) 有没有比较开心！至少我有。:D 当然这个 syntax 本身还是有可能是参考其他语言 而来，不过精神上肯定是从 Objective-C 传承来的。 SWIFT 在概念上就是 OBJECTIVE-C Swift 的很多概念根本是从 Objective-C 照抄的。这在很多地方都看得出来。我在 PTT 讲过记忆体管理，另外单继承与 protocols 的概念也是如此（而不是来自 C#）。 当然这有好有不好，不过至少对於已经熟悉 Objective-C 的人而言，这应该非常亲 切。 苹果在设计 Swift 时，完全没有改变它背後的理念，只是为了这些理念创造了全新 的语言，而不再继续使用基於 C，而需要背负许多包袱的 Objective-C。你从 Objective-C 学到的东西还是能够继续使用，只是因为它们现在不再基於 C，而会有 些语法上的变化（通常是简化）。 Tim Cook 在 keynote 讲的话不是效果而已，其实 Swift 真的就是 Objective-C without the C 啊。 http://www.blogcdn.com/www.engadget.com/media/2014/06/wwdc2086.jpg --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 218.161.94.175 ※ 文章网址: http://webptt.com/cn.aspx?n=bbs/MacDev/M.1401811778.A.508.html