Pofat 的話
Protocol,generic 以及 value type 是 weak self 節目的初始議題,同時也是今年 Swift 最大的改進重點,每次講到它們都有說不完的話題,這期來和大家好好聊聊。與其它使用教學類型的文章不同,我會著重於泛型背後的「思想」與 Swift 的設計如何呼應,大家也可以當做散文閱讀。
還有一件要事,本週 weak self 在剛過三週年不久後達到了一百集的里程碑(?!),感謝大家的陪伴,聽節目由此去:weak self podcast 99: 理直氣壯的綜藝技術節目.幹一年不如等一年。
什麼是 any 和 some ?談Swift 的泛型思想 (上)
Swift 5.1 引入了 some 而 5.7 正式可以使用 any ,這兩個關鍵字看似相似但又有大不同,一起從軟體工程的思想原則來看看為什麼會有這些東西的存在。
有軟體開發經驗的讀者,應該都能認同「抽象」是程式開發的基礎方法,而這套方法其實可追溯至西元前三百多年,由注重實際觀察實際經驗的哲學家亞里斯多德提出的概念,不得不說注重觀察這點倒是跟我這種工程師本質相通呢!
而這概念點出了「如何抽象」的分層基礎: individual,species 與 genus,此三層的概念至今都充斥在我們的開發日常中。
Individual 是指我們真實互動的實際對象,也被稱之為第一實體。比如 13 和 喬喬 (偷偷用他們當主角)都各是不同的 individual,在程式裡對應的角色就是實例(Instance)。
Species ,genus 則都是透過理性觀察,抽取出其特質並用來描述、分類的單位,某種程度地表示 individual 的本質,也被,species 則對應到程式就是型別(Type) ,承上例,13 和喬喬都是 Apple 開發者:
struct AppleDeveloper {
let name: String
}
let ethan = AppleDeveloper(name: "13")
Genus 則是更上層的分類,對應的角色可以是 super class,或者是 Swift 的 generic ,至此我們應該可以看到我們可以把事物以樹狀的結構分類。然而單純僅以樹狀架構分類遇到的困境便是欠缺彈性,比如開發者還可以是週報創作者,podcaster 等。因此我們需要另一個工具可以幫助我們描述「只著眼於眼前在乎特性,且無視 species 」的集合。
數學中抽象代數的領域給這件事帶來了實際的方法依據,其精神就是「我們可以在完全不了解某些數實體的實際結構下,確定這些實體的數學結論」,如果你覺得聽起來很耳熟,這就是 Swift 裡的 protocol 。(註:抽象代數由傑出的 Emmy Noether 所完備,我找了篇關於她生命故事的短文,有興趣請由此前往閱讀。)
Swift 中提供了兩種層級的抽象工具,在型別層級的抽象工具是 generic 以及 some
,我們需要更多跨物種彈性時的最佳工具,比如到餐廳用餐,而餐廳接受的付款方式是信用卡(genus),但實際上信用上又分成不同銀行分發的卡(species),而 Swift 保證接受到的參數是「某個遵循該 protocol 的型別之實例」, 於是乎我們可以這樣寫程式:
func take(payment: some Payable) -> Result
然而值層級的抽象工具是 existential container ,一個包裝著遵循某 protocol 實例的容器。值抽象的行為在我們的生活中其實很常見,同樣在餐廳場景裡,常會遇到一些無法忍受事物不依他期待進行的人,受到不如意的待遇後便暴怒拍桌,大喊「叫你們經理出來!」
各位,這正是在進行一個抽象的行為啊!因為他根本不在乎經理是「哪種人」(型別),只在乎對方能不能出來給個交代,而且要求的對方是一個獨立個體(實例),化成程式碼就是:
protocol 經理 {
func 出來() -> 交代
}
let 誰都好: any 經理 = 某經理()
誰都好.出來()
不過實際上的需求更複雜,any
和 some
解決的問題比我們所想的還要多,我們下周待續。
Swift 新聞
`is case`
的早期提案
寫過 Swift Regrets 系列的 Jordan Rose 本週點出了一個每年都有人呼喊的功能,即「一行判斷是不是某一個 enum case 」的語法。現在的 enum 辦不到,除非讓它遵循(conform to) Equatable ,如果 enum 本身又有 associated value,無可避免地要加一堆模版程式碼。提案內容一碼以蔽之:
result is case .success(_)
result is case .failure(MyError.fileNotFound)
此文很新底下討論還不多,不過這個初期提案讓我意識到提出新語法或用例應聚焦的重點(雖然再想想又覺得理所當然)與思想流程:先講期許,接著是使用場景。
語法的暗示性會給大家用法的連想,is case
很顯然地告訴我們這是一個判斷式(這裡當然就可會有不同聯想或更多語法上的點子),接下來就要考慮各種判斷式的場景使用的情況,比如下例怎麼判讀比較合理?
x ?? y is case .success(_)
我認為這是個對想入坑 Swift 討論串、開發很適合的起始之堆。
喜迎 any Equatable
與 any Comparable
新語法出現後,我們終於又能像以前 OC 時代一樣隨便把兩個東西拿來比較了呢!不論是比較是否相等:
或是比較大小都可以:
Pofat 選推
再次驗證各做工行業的雷同...
一秒搞懂 Swift compiler 架構:
請使用者給 app 評分的新語法,但我在這學到了 callAsFunc 的實用用法,iOS 15 就開始支援的 dismiss 也是採用一樣的方式。
滿有道理的
Every. Single. Day.
媽我上榜的了(?)
叫經理出來那段笑死我了