2011-02-13 7 views
2

私はランタイムで遊んでいましたが、匿名クラスを生成するobjc_allocateClassPair/objc_registerClassPairの代替案が考えられました。自分のカスタマイズしたobj-cランタイムにアプリケーションを静的にリンクするのは簡単でしょうか?

匿名のクラスは、私が取り組んでいるものにとっては非常に便利ですが、ランタイムの不透明なデータ型が実装されている方法に依存するので、私は心配しています(私の知る限り、ランタイムは共有ライブラリですOSのバージョン間でこれらのタイプのレイアウトを変更する可能性があります)、問題を求めています。

より一般的には、ランタイムはオープンソースであるという事実は、言語と創造のための特定の可能性を開いているようだ...

する方法は簡単、それは静的に共有するのではなく、私の修正ランタイムにリンクするだろう1?私はコンパイラを混乱させる必要がありますか、それは他のライブラリにリンクするようなものでしょうか。

これがどのようにApp Storeの承認に影響を与えるかにも興味があります。

答えて

4

おそらく、それは最終的には価値があるよりもトラブルです。確かに、システムフレームワークで使用されているランタイムを置き換えることは望ましくありません。それは不可能である(または確かに非常に難しい)だけでなく、システムレベルでしか実行できない多数の最適化があるため、あなたのアプリを控えめに遅くする可能性が非常に高いです。

このようにするには、コンパイラやリンカの重要な意味が必要になります。また、境界の問題にぶつかります。あなたのコードへの呼び出しまたはシステムへの呼び出し(2つのランタイムを並行して実行しようとする場合、不可能である可能性があります)です。

評価では、現在のランタイムのメタデータのレイアウトに依存していることは間違いであることは間違いありません。 Obj-C 2.0の移行では、すべてのメタデータがAPIの背後に置かれ、[適切に記述された]アプリケーションを破棄することなくメタデータを大幅に変更できるようになりました。

クラス内の機能の一部のサブセットに対して新しい/異なるランタイムモデルが本当に必要な場合は、システムランタイムから可能な限り分離することをお勧めします。新しいルートクラスが興味深いかもしれませんが、フレームワーククラスを混在させると脆弱になりがちです。

+0

私はシステムフレームワークの問題がそれを殺すと思います。私が知っている限り、Foundationは実行されるランタイムのバージョンを前提にして、10.7のフレームワークがランタイムのブランチに対して10.6からリンクされていると、恐ろしく壊れてしまいます。 –

関連する問題