Ce n' @package directive ne s'en Objective-C?

Question

Personne ne sait exactement ce que l' @package directive est utilisée pour en Objective-C?

La seule mention que j'ai pu trouver dans la Programmation en Objective-C 2.0 par Stephen Kochan était:

@package - Pour la version 64 bits des images, la variable d'instance peut être consulté n'importe où dans l'image qui implémente la classe

...

Quoi? Est-ce limité à être utilisé avec des images, comme dans les photos? Ou signifie-t-il des images comme dans les images de disque?

C'est une source de confusion description, et ne m'étendrai pas que ce soit tout au long du reste de l'ouvrage....

Toute aide serait génial, merci!

Answer 1

@package est similaire à l' internal .NET. Cela signifie que le membre est accessible uniquement à partir du cadre dans lequel elle est définie.

Remarque: En 32 bits, il agit comme @public.

Answer 2

La documentation d'Apple explique un peu, mais voici un peu plus en détail...

Les variables d'Instance qui sont déclarées en vertu de l' @package seront uniquement accessibles par code à partir du même cadre, une bibliothèque ou un exécutable. C'est plus semblable à l' internal en C# et Friend dans VB.NET mais d'autres langages de programmation ont des protections similaires de systèmes (Java a package-private).

Par exemple, imaginer un cadre, RecipeKit.framework, pour la gestion des recettes:

@interface Recipe : NSObject {
  @package;
    NSString *name;
  @private;
    NSArray *ingredients;
}
@end

@interface RecipeController : NSObject
@end

La recette contrôleur sera en mesure d'accéder aux noms de recettes directement. Vous pouvez écrire quelque chose comme ceci dans l' RecipeController puisqu'il fait partie du même cadre:

Recipe *recipe = [[[Recipe alloc] init] autorelease];
[recipe->name autorelease];
recipe->name = [@"The best ever recipe!" retain];

Si vous deviez écrire le code ci-dessus dans une application reliant RecipeKit, cependant, il serait la cause d'une erreur de compilation puisque vous n'avez pas accès à cette variable. Enfin, lors de la compilation de 32 bits, les variables déclarées en vertu de l' @package se comportent comme si elles étaient déclarées en vertu de l' @public au lieu de cela, donc attention pour les différences ici.

Cette nouvelle fonctionnalité a eu très peu d'attention parce que c'est juste une façon de plus de la rupture que vous êtes de la classe d'encapsulation. Comme cela a toujours été vrai, vous êtes probablement mieux de travailler avec des @private des variables, et d'avoir des méthodes accesseur pour eux. En fait, pour un tandis que Apple a essayé de pousser en incluant @private dans leurs modèles. Avec des propriétés en Objective-C 2.0, coller avec @private est assez facile, et en fonction de ce que la plateforme que vous ciblez, vous pouvez laisser les instances des variables entièrement.

---

Images

Une chose qu'un peu de la réponse à la question précédente a laissé un peu floues sur l'aspect des images à partir de la question d'origine. En fait, le mot image utilisée dans la description de l' @package variables n'a rien à voir avec les images graphiques. Au contraire, c'est en se référant à des images que l'éditeur de liens dynamique est en mesure de charger. Généralement, les exécutables, les cadres et les bibliothèques dynamiques sont tous considérés comme des images par l'éditeur de liens (même si elles sont traitées de façon légèrement différente). Vous verrez le mot image pop-up à chaque fois. Par exemple, une commune erreur d'exécution est: "dyld image n'est pas trouvée". Vous trouverez également l'utilisation du mot image dispersés dans toute la documentation pour l' dyld. La lecture par le biais de la page de man pour dyld pourrait aider à lever l'ambiguïté de ce mot un peu. UIImage peut déclarer des variables en tant que @package, mais il n'a rien à voir avec l'image qu'il se rapporte à la question d'origine.