2009-09-24 7 views
0

J'ai une application pour Mac OS X qui supporte les plugins qui doivent être chargés en même temps. Certains de ces plugins sont construits sur un framework Cocoa qui peut recevoir des mises à jour dans un plugin mais pas dans un autre. Étant donné la méthode actuelle d'Objective-C pour la répartition des fonctions, tout appel d'un plugin à une routine Objective-C donnée ira à la même routine à chaque fois. Cela signifie que le plugin A peut se trouver dans le plugin B avec un appel trivial Objective-C! Évidemment, ce que nous recherchons, c'est que chaque plugin interagisse avec sa propre version du framework sur lequel il a été construit. Ihavebeenreading certains sur Objective-C et ce besoin particulier, mais n'ont pas encore trouvé une solution définitive pour cela.Collisions de répartition de la fonction Objective-C; Ou, comment réaliser des "espaces de noms"?

Mise à jour: Mon utilisation du mot «framework» ci-dessus est trompeuse: le framework est une bibliothèque statiquement liée, intégrée dans le (s) plugin (s) qui en ont besoin. Cependant, la manière dont Objective-C gère le dispatching, même ces parties de code disparates liées de manière statique vont se mêler dans le répartiteur Objective-C, entraînant des conséquences inattendues.

Mise à jour 2: Je suis encore un peu flou sur le answer provided here, car il ne semble pas proposer une solution autant qu'une hypothèse non prouvée.

+0

Voir http: // stackoverflow.com/questions/178434/quoi-est-le-meilleur-moyen-de-résoudre-un-objectif-c-namespace-collision –

Répondre

0

Je ne pense pas avoir compris que vous commentez "le plugin A peut se trouver dans le plugin B." Je suppose que vous voulez dire qu'une fois que vous avez chargé un cadre dépendant une fois, alors tout le monde va l'utiliser plutôt que de charger le sien, et c'est correct. Et c'est correct si vous avez quelque chose comme des espaces de noms ou non.

C'est le même problème auquel vous seriez confronté si un plugin nécessitait une version d'OpenSSL, et qu'un autre plugin nécessitait une autre version d'OpenSSL. Vous ne pouvez pas charger deux bibliothèques fournissant les mêmes symboles.

Est-ce que je comprends le problème? Divers plugins nécessitent des versions différentes et incompatibles du même framework? Mon approche, si possible, serait de changer le framework en une bibliothèque statique et de lier statiquement vos plugins à leur framework. Si vous ne partagez pas le framework entre les plugins, alors un framework n'est vraiment pas ce que vous voulez. Vous voulez simplement compiler le code (lien statique). Le but d'un cadre est de partager.

+0

C'est la chose - si les bibliothèques sont statiquement liées, vous êtes aussi grillé; la façon dont Objective-C gère le dispatching * tout * est gérée par un seul répartiteur, donc deux plugins complètement différents, 100% statiquement liés, peuvent se retrouver à appeler par inadvertance les routines de l'autre. – fbrereto

1

Vous ne pouvez pas faire cela (du moins pas de manière triviale), Objective-C n'a actuellement aucune notion d'espaces de noms, et l'exécution ne présente qu'une seule table de répartition (globale). Notez que ceci n'est pas unique à Objective-C, même les plugins basés sur C peuvent aussi appeler entre eux de manière assez triviale, puisque tout est dans le même espace d'adresse. Certes, si vous vous inquiétez de le faire accidentellement, c'est moins probable à cause des espaces de noms à deux niveaux, mais ceux-ci ne vous protégeront pas si un plugin essaie explicitement d'entrer un autre code. Si vous voulez vraiment isoler les plugins, vous pouvez créer des processus d'assistance séparés où vous exécutez le code qui charge le plugin et demandez à votre application d'effectuer des RPC entre elle et les applications auxiliaires. C'est ce que fait Safari en 64 bits sur Snow Leopard, par exemple. Cette approche présente un certain nombre d'avantages, mais elle est assez complexe à mettre en œuvre et vous devez en faire la majeure partie vous-même.

Questions connexes