siuying 積分 1

這麽一個重點功能,居然無聲無息就消失了

siuying 積分 0 編輯於

再舉一個例子:

[array appendContentsOf:@[@2, @3, @4]]; 變成 array.append(contentsOf: [2, 3, 4]) 重點是 Swift 化而不是縮短

siuying 積分 0

是詛咒或是祝福,視你的心情而定 :)

siuying 積分 1 編輯於

這次改變1 重點真不是方法長短 :

-public func readLine(stripNewline stripNewline: Bool = true) -> String?

+public func readLine(strippingNewline strippingNewline: Bool = true) -> String?

siuying 積分 0

BTW the idea behind is still the same "clarity over brevity"

siuying 積分 0

no, they automatically convert Objective-C convention to Swift conventions. So when you use Swift, you write eloquent Swift code, and when you write Objective-C, you write eloquent ObjC code.

I think this is one of a kind and Apple is the first one did something like that, impressive feat. They even translate C based API to object like API: Import As Member1

siuying 積分 0

How about SmartOS, I don't know much about it but it seems its their core business.

siuying 積分 2

Redux 在文件 Async Actions1 中有說到,這時候通常用 redux trunk middleware 寫一種叫 Action Creator 的東西。儲存理應放在 Store 。

不喜歡 Redux 的地方就是這種造一大堆新的 abstraction 出來,而且也不是唯一的做法,新手不知道對不對。

siuying 積分 1

其實這不奇怪,因為 Facebook 自己重新用土法 Implement List View ,又不像 iOS UITableView 那樣 reuse views ,在長的 list 當然慢到七彩。

siuying 積分 0

連簡單如 Table 也要另外用 native 的 Component Kit 才行,我真不知這算不算成功了

siuying 積分 0

不是啊,是 Apple 在 WWDC 前先公佈這個大消息,即是說蘋果有太多東西要說 Keynote / Platforms State of Union 兩場也講不完

siuying 積分 1

我覺得他們是欠下很多技術債,因為 React Native 做不到很多事他們混用了不同的技術。省下來的跨平台代碼只是一些表面和簡單的介面 (Flux Store/Action),但卻加大了整合的難度,要理解整個專案也得同時懂得 iOS, React Native 和 Component Kit (ObjectiveC++) 才行。

siuying 積分 0

還可以上訴.

要真正脫離 Oracle 魔咒除了新語言還要新 Standard Library 和 Framework,因為 API 有版權... 好像 Apple 那樣用聰明的方法把舊 API map 成 Swift 風格 API 也不行。

siuying 積分 3

因為一個人的 modules 讓大量 package 不能 build ,因此 npm 要把這個 unpublished 的 package un-unpublish,這事已被稱為 #npmgate 了。

siuying 積分 0

我就是說你的推論全錯了,要是 dangling pointer 是 crash 的主因,那在沒有 dangling pointer 的地方就很少 crash 了,對不?

siuying 積分 0

很難説大部分原因,因為有很多原因。這樣說吧,android app用 vm 有 GC, 閃退會比較少嗎?據我看的統計不是這樣。

siuying 積分 0

所以我們會用Swift,一個不會有NullPointerException的語言. 至於memory mamagement就交給compiler專家做...

siuying 積分 0

你是誤會了甚麼, mobile app 是會 crash, 但很少是因為'dangling pointer'. 你說的'哪個app不閃退'和Memory management根本沒直接關係好不好?

「完全不全會踩錯的GC」如果GC可以完全不會踩錯, ARC為何不可呢?

siuying 積分 0 編輯於

至於crash就是另一個問題, 那也不一定只是 dangling pointer (Swift 本身沒有pointer, 你不用 C code / UnsafePointer 想搞出個 dangling pointer 也還不易), 但nginx Apache httpd 也是用C 寫不見得有問題。

siuying 積分 0

這種「X不是萬能的」有甚麼用呢?GC也不是萬能的, 我也見過Java 的 Server process OOM。

siuying 積分 0

有關 GC, 正好相反, Swift 的 ARC 原理是自動加入 alloc/dealloc, 所以有一個(理論上)穩定的 memory model。比如某個Variable已經不會再用, 那compiler就可以立即把那些memory release。