0

同時にロードされるプラグインをサポートする Mac OS X 用のアプリケーションがあります。これらのプラグインの一部は Cocoa フレームワークの上に構築されており、あるプラグインでは更新を受け取り、別のプラグインでは受け取らない場合があります。Objective-C の現在の関数ディスパッチ方法では、任意のプラグインから特定の Objective-C ルーチンへの呼び出しは、毎回同じルーチンに送られます。つまり、プラグイン A は簡単な Objective-C 呼び出しでプラグイン B内にあることを確認できます。明らかに、私たちが探しているのは、各プラグインが、それが構築されたフレームワークの独自のバージョンと対話することです。私 はObjective-Cとこの特定の必要性についていくつか 読んでい ますが、まだ決定的な解決策を見つけていません.

更新: 上記の「フレームワーク」という言葉の使用は誤解を招くものです。フレームワークは静的にリンクされたライブラリであり、それを必要とするプラグインに組み込まれています。ただし、Objective-C がディスパッチを処理する方法では、これらの静的にリンクされた異種コードの断片でさえ、Objective-C ディスパッチャ内で混ざり合い、意図しない結果につながります。

更新 2:証明されていない仮説ほど解決策を提案していないように見えるため、ここで提供される回答についてはまだ少しあいまいです。

4

3 に答える 3

1

それを行うことはできません (少なくとも自明ではありません)。現在、Objective-C には名前空間の概念がなく、ランタイムは単一の (グローバル) ディスパッチ テーブルのみを提示します。

これは Objective-C に固有のものではないことに注意してください。C ベースのプラグインでも、すべてが同じアドレス空間にあるため、相互に簡単に呼び出すことができます。確かに、2 レベルの名前空間があるため、誤って実行してしまう可能性は低いですが、一部のプラグインが別のコードを明示的に入力しようとすると、それらはあなたを保護しません。

本当にプラグインを分離したい場合は、別のヘルパー プロセスを作成して、プラグインをロードするコードを実行し、アプリケーションにそれ自体とヘルパー アプリの間で RPC を実行させることができます。これは、たとえば、Snow Leopard の 64 ビットで Safari が行うことです。このアプローチには多くの利点がありますが、実装がかなり複雑であり、そのほとんどを自分で展開する必要があります。

于 2009-09-24T23:38:51.520 に答える
0

「プラグイン A はプラグイン B 内にある」というあなたのコメントが理解できないと思います。依存するフレームワークを一度ロードすると、誰もが独自のフレームワークをロードするのではなく、それを使用するようになるという意味だと思いますが、それは正しいです。名前空間のようなものがあるかどうかに関係なく、それは正しいです。

これは、あるプラグインがあるバージョンの OpenSSL を必要とし、別のプラグインが別のバージョンの OpenSSL を必要とする場合に直面する問題と同じです。同じシンボルを提供する 2 つのライブラリを読み込むことはできません。

私は問題を理解していますか？さまざまなプラグインには、同じフレームワークの互換性のない異なるバージョンが必要ですか? 私のアプローチは、可能であれば、フレームワークを静的ライブラリに変更し、プラグインをフレームワークに静的にリンクすることです。プラグイン間でフレームワークを共有していない場合、フレームワークは本当に必要なものではありません。コードをコンパイルするだけです (静的リンク)。フレームワークの要点は、共有することです。

于 2009-09-24T23:34:31.170 に答える
0

これまでの最善の解決策は、この質問で提案されたアイデアから派生したものです

于 2010-04-14T22:27:37.260 に答える