Swift Is Objective-C without the C, Period.

[uranusjr (←這人是超級笨蛋)]

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://www.ptt.cc/bbs/MacDev/M.1401811778.A.508.html
推 TsaoCCFGOGO:專業好文！推！
推 Piceman:推一下，講的很清楚
推 manlike:ObjectiveC的method超廢，呼叫一個method寫一大串 LOL
→ manlike:根本神經病，什麼可讀性，還不是要靠IDE和文件~ XDDD
→ manlike:不要講可讀性，可用性更是笑話，寫參數名稱浪費時間又干擾
→ manlike:寫程式的順暢度和思考邏輯，閱讀上一堆字，視力要很好LOL
推 kiii210:推
→ manlike:話說，不知道有沒有人用vi寫 Objective-C ? XD
→ Deltaguita:不要講這麼白，果粉會生氣...
→ tommy60703:Manlike大，Obj-C的方法是可以不取參數名稱只用冒號分
→ tommy60703:開的，但我還是愛用落落長的名字，對我來說真的增加很
→ tommy60703:多可讀性，反正Xcode的自動完成很方便彈指就寫完了
推 kiii210:我覺得Obj-C這樣寫method還滿清楚明白的呀
→ kiii210:ps.我只寫過Obj-C
→ kiii210:Swift這樣要習慣一下就是
→ uranusjr:@manlike 你開心就好, 沒人逼你寫; 反正你也只會隨口憑感
→ uranusjr:覺放話, 講錯被電就離脫嘛, 別人說什麼也沒用
推 Blueshiva:a("manlike",0,null,false,"shit") <-可讀性多好啊！
推 Deltaguita:你看，生氣了
→ tom19830924:我也覺得Objective-C的方法名稱很清楚 我記得以前看
→ tom19830924:語言教學的時候還有提到這是優點啊 越長越清楚越好
推 SwiftLang:大家好
→ SwiftLang:以後請大家多多指教喔!
→ tkdmaf:樓上昨天剛出生？？？
→ tkdmaf:以後每年的6月2日(美國時間)就是SwiftLang的生日了。
推 Killercat:Obj-c的method算是一種用ide enhanced下的可讀性
→ Killercat:很難說好還是不好，當一個method參數是20個string的時候
→ Killercat:應該是不會有人覺得C-like的寫法讓人愉悅啦
→ Killercat:至少Obj-c裡面20個String在使用的時候都會有清楚的名字
→ Killercat:在C/C++底下也是得靠很強大的IDE才不至於弄混
→ Killercat:(我知道20個String的arguments很爛 不過這只是舉例 舉例
→ Killercat:不過我始終無法對無法定型的容器有好感 =___=
→ Deltaguita:20個String 不考慮用vararg 或struct?
→ Deltaguita:有沒有"更"合理的解釋方式
→ Killercat:不用20啊 四個就夠你受了好嗎...尤其是POD :D
→ Killercat:有個人沒說錯，Obj-C method寫法的確是比較吃IDE才好用
→ Killercat:但是這不代表你可以用「你看果粉生氣了」來扯爛汙啊...
→ Killercat:你覺得它爛 sure 我甚至能理解 但是嘴巴乾淨點
→ Killercat:一堆人上班眼睛已經吃夠多屎了 大家包容點吧
→ Killercat:吵架在所難免 討罵真的就免了 沒建設性
推 Blueshiva:"更"合理的解釋方式？沒有，也不需要，偏見是非理性的
推 ian90911:推
推 ZZB:扣帽子噴一句話的沒建設性發言就省省吧
推 sorkayi:不管 Obj-C 才是全世界最棒的語言
→ cha122977:吃IDE其實也沒什麼關係，很少人不用X-CODE寫obj-c的吧
推 wfgh:不知道有沒有人用vim開發android
推 Killercat:當然有 開發NDK程式的時候還是vim好用(這是語病嗎 XD)
→ Killercat:我家老闆以前開發iphone也用vim寫obj-c 看得我直皺眉XD
→ Killercat:不過天才都有一些怪僻啦 既然我家老闆是個天才 那就算了
→ TsaoCCFGOGO:vim 應該也可以 auto-completion, 只是 terminal size
→ TsaoCCFGOGO:要夠大，不然自動換行很痛苦 XD