>「言葉の定義で議論するつもりはない」と言っておきながら、
>「Cocoaはnativeじゃない」って再度言ってるのがやはりわからん。

特に矛盾はしていないつもりだが？
>>836で書いた「nativeなAPI」というのが伝わらなかったから
具体例で答えただけ。定義で議論する必要がないように。

>ちなみに、IPCやThreadの細かいコントロールなんかも、Carbonじゃあできないよね。

pthreadとNSThread、MultiprocessingServiceの機能を比較した上で言っている？
NSThreadはかなり高機能かつ簡略化したプログラミングモデルになっていて、
あまり細かいコントロールはできなかったはず。
それにNSThreadからpthread_tを得る方法も用意されていないから、もし本当に
細かいコントロールが必要なら、NSThreadを使わず最初からpthreadでプログラミング
する必要がある。

>>854
>(1)Cocoaで用意されている機能を使うのは本当に楽なのか、
>(2)Carbon諸々の関数を使う時の制限。
>(2')Cocoaはどれほどの機能が用意されているのか。
>たぶん、(2)の制限がないのなら相対的には(2')は欠点にならないでしょ。

すくなくとも俺は、Cocoaでの開発は非常に楽だと思っている。
問題はCocoaでカバーしていない、あるいは隠されている部分についてなんだ
けれども、それらは以下のように分類できる。
1.Cocoaとは独立に利用できるもの
2.Cocoaと、CarbonなりBSDなりの間の連係手段が用意されているもの
3.Cocoa側からは隠されていて、アクセスの方法がないもの
問題は3番目。もちろんどのAPIもコールすることは自由にできるわけだけど、
その場合は上で書いたNSThreadの例のように、Cocoaでカバーされている
部分もまるごと放棄することになる。あるいはイベントハンドリングのように
Cocoa側にフックを用意してくれないことには手を出せない部分もあるし。
現在のCocoaはまだまだこのような部分が多く残されているように思っている。
＃それはOPENSTEP→YellowBoxという、永くプラットフォーム非依存であった
＃歴史にも由るのだと思うけど。