Brent Simmons 在 解決目前不存在的問題,就好像問題存在一樣 中說到:
Swift 的類型體系解決了我沒碰到的一個問題。
對這句話我深有同感,而且我敢打賭很多其他的 Objective-C 開發(fā)者也會這樣覺得。
在我剛開始嘗試使用 Swift 時,編譯器似乎經(jīng)常和我做對 1 。但隨著我對這門語言越來越熟悉,情況也隨之變得好起來,但是有時它奇怪的錯誤信息還是會讓我覺得它是一個難以取悅的任性小孩。
在這樣的情況下,Swift 嚴格的類型檢查所帶給你的好處相比你為了讓代碼運行所付出的努力就少之又少了。即便如此,它的類型體系還是在去年成長到了讓我再也不想錯過它的程度。
相比 Objective-C 我更喜歡 Swift 最大的原因不是他的類型體系,而是一些更平凡的特性
integer
或者 struct
在不使用 object
包裝的情況下就放到 array
中,這可以說是大贏,因為這意味著我們可以對這些類型進行擴展。簡而言之,Swift 是現(xiàn)代語言,而 Objective-C 顯然不是。
如果 Apple 在去年發(fā)布了真正的 “Objective-C 3.0”,在保留 Obj-C 動態(tài)特性的情況下使其現(xiàn)代化 2 ,我將會更加開心并且可能永遠不會主張更加靜態(tài)的類型檢查。畢竟,“我知道我所做的事情,而且我永遠不會因為數(shù)組里面包含意外類型而導致錯誤?!?/p>
但是 Apple 給了我們 Swift, 而不是 Objective-C 3.0。Swift 的發(fā)布促使我去了解其他有同樣類型體系的語言,比如 Haskell,ML 和 Scala。我從那些社區(qū)學到的特別的一點就是 hole-driven (或編譯驅(qū)動)開發(fā) :不要把編譯器當作需要你對抗的一股力量,而是把它當作可以解決你問題的一件神器,根據(jù)類型一步一步滴來。
Hole-Driven 開發(fā)在構建數(shù)據(jù)結構模型和數(shù)據(jù)轉(zhuǎn)換時可以說是夢幻般的技術( Haskell 和它的同類尤其擅長),而且盡管還有可提升的潛力,它在 Swift 中依然表現(xiàn)滴相當棒。煩人的編譯器和有益的編譯器最關鍵的不同點在于它的錯誤信息是不是易于理解,而很多 Swift 的診斷信息仍然相當神秘 3 。
對于典型的 GUI 編程, 編譯驅(qū)動開發(fā)可能沒那么有用,盡管我認為這主要歸根于 Cocoa API 的設計而不是編譯驅(qū)動開發(fā)固有的限制。像 ReactiveCocoa 這樣的庫就向我們展示了類型體系(在一定程度上說應該是清晰的語法)設計出來的 API 是什么樣的。當你可以依賴一個幸虧有泛型的編譯器來做多步的 復雜信號變換 ,保證結果的正確性將會變得更加簡單。現(xiàn)在我發(fā)現(xiàn)在 Objective-C 中寫這樣的代碼要難得多(隨后也更難理解),因為我需要在我腦海中記更多的東西。
嚴格的類型體系帶來的另外一個巨大好處就是做為副產(chǎn)品生成的自動文檔。做為 Apple 平臺上的開發(fā)者,我們訪問不到我們最常使用的庫的源代碼,所以我們需要依賴文檔。編譯器強制 API 設計者提供的信息越多,使用 API 的人就越方便。單可選注釋就給 Cocoa 的文檔提供了極大的提升 4 。想象一下如果所有 Cocoa 的 API 的方法參數(shù)和返回值類型都是 id
。頭文件基本上就沒什么用了。
在強制我自己對類型進行非常仔細的思考之后,我發(fā)現(xiàn)我 Swift 代碼的設計更好了,也更容易維護了。我對我代碼的正確性也更加有自信了,而且更奇怪的是:寫起來也更有趣了?。≒S:此處有強烈的補腎丸廣告即視感)
Swift 仍然在起步階段。有時它可能會讓你沮喪,但是隨著時間的推移編譯器提示的錯誤信息會更友好,甚至可以讓你的代碼更加合理。比如說我們都在糾結的一個例子,并發(fā):如果編譯器可以靜態(tài)滴證明你的多線程代碼不存在沖突,那就是一個巨大的優(yōu)勢。Swift 現(xiàn)在還不能做,但是 Rust 可以 。對次我相當興奮。
<a name="1">1.這也是我覺得 Swift 果斷不是一門易學(易教)語言的原因之一。另外一個就是復雜的標準庫</a>
<a name="2">2.我們幾十年來都在使用“沒有 C 的 Objective-C”,而是以 Smalltalk 的形式</a>
<a name="3">3.毫無疑問,至少有一部分原因是我對語言比較陌生</a>
<a name="4">4.我需要提醒大家的是注釋是不保證正確性的,所以嚴格滴說它們沒有頭文件注釋可靠。也許有人會認為僅僅一個嚴格的編譯器就可以強制讓 Apple 的文檔更加精確。</a>
更多建議: