Existe-t-il des collections fortement typées en Objective-C?

Je suis nouveau dans la programmation Mac / iPhone et Objective-C. En C # et Java, nous avons des "génériques", des classes de collection dont les membres ne peuvent être que du type déclaré. Par exemple, en C #

Dictionary<int, MyCustomObject>

ne peut contenir que des clés qui sont des entiers et des valeurs de type MyCustomObject. Existe-t-il un mécanisme similaire en Objective-C?

Dans Xcode 7, Apple a introduit des «génériques légers» dans Objective-C. En Objective-C, ils généreront des avertissements du compilateur en cas d'incompatibilité de type.

NSArray<NSString*>* arr = @[@"str"];

NSString* string = [arr objectAtIndex:0];
NSNumber* number = [arr objectAtIndex:0]; // Warning: Incompatible pointer types initializing 'NSNumber *' with an expression of type 'NSString *'

Et dans le code Swift, ils produiront une erreur de compilation:

var str: String = arr[0]
var num: Int = arr[0] //Error 'String' is not convertible to 'Int'

Les génériques légers sont destinés à être utilisés avec NSArray, NSDictionary et NSSet, mais vous pouvez également les ajouter à vos propres classes:

@interface GenericsTest<__covariant T> : NSObject

-(void)genericMethod:(T)object;

@end

@implementation GenericsTest

-(void)genericMethod:(id)object {}

@end

Objective-C se comportera comme avant avec les avertissements du compilateur.

GenericsTest<NSString*>* test = [GenericsTest new];

[test genericMethod:@"string"];
[test genericMethod:@1]; // Warning: Incompatible pointer types sending 'NSNumber *' to parameter of type 'NSString *'

mais Swift ignorera complètement les informations génériques. (Ce n'est plus vrai dans Swift 3+.)

var test = GenericsTest<String>() //Error: Cannot specialize non-generic type 'GenericsTest'

Mis à part ces classes de collection Foundation, les génériques légers Objective-C sont ignorés par Swift. Tous les autres types utilisant des génériques légers sont importés dans Swift comme s'ils n'étaient pas paramétrés.

Interagir avec les API Objective-C

Cette réponse est dépassée mais reste pour une valeur historique. À partir de Xcode 7, la réponse de Connor du 8 juin 15 est plus précise.

Non, il n'y a pas de génériques en Objective-C à moins que vous ne souhaitiez utiliser des modèles C ++ dans vos propres classes de collection personnalisées (ce que je déconseille fortement).

Objective-C a le typage dynamique comme fonctionnalité, ce qui signifie que le runtime ne se soucie pas du type d'un objet puisque tous les objets peuvent recevoir des messages. Lorsque vous ajoutez un objet à une collection intégrée, ils sont simplement traités comme s'ils étaient de type id. Mais ne vous inquiétez pas, envoyez simplement des messages à ces objets comme d'habitude; cela fonctionnera bien (à moins bien sûr qu'un ou plusieurs objets de la collection ne répondent pas au message que vous envoyez) .

Les génériques sont nécessaires dans des langages tels que Java et C # car ce sont des langages forts et typés statiquement. Jeu de balle totalement différent de la fonction de frappe dynamique d'Objective-C.

Non, mais pour être plus clair, vous pouvez le commenter avec le type d'objet que vous souhaitez stocker, j'ai vu cela plusieurs fois lorsque vous avez besoin d'écrire quelque chose en Java 1.4 de nos jours) par exemple:

NSMutableArray* /*<TypeA>*/ arrayName = ....

ou

NSDictionary* /*<TypeA, TypeB>*/ dictionaryName = ...

Il n'y a pas de génériques dans Objective-C.

À partir des documents

Les tableaux sont des collections ordonnées d'objets. Cocoa fournit plusieurs classes de tableaux, NSArray, NSMutableArray (une sous-classe de NSArray) et NSPointerArray.

Apple a ajouté des génériques à ObjC dans XCode 7:

@property NSArray<NSDate *>* dates;
- (NSArray<NSDate *> *)datesBeforeDate:(NSDate *)date;
- (void)addDatesParsedFromTimestamps:(NSArray<NSString *> *)timestamps;

voir ici: https://developer.apple.com/library/prerelease/mac/documentation/Swift/Conceptual/BuildingCocoaApps/WorkingWithCocoaDataTypes.html#//apple_ref/doc/uid/TP40014216-CH6-ID61

Cela a été publié dans Xcode 7 (enfin!)

Notez que dans le code Objective C, il s'agit simplement d'une vérification à la compilation; il n'y aura pas d'erreur d'exécution juste pour mettre le mauvais type dans une collection ou l'assigner à une propriété typée.

Déclarer:

@interface FooClass <T> : NSObject
@property (nonatomic) T prop;
@end

Utilisation:

FooClass<NSString *> *foo = [[FooClass alloc] init];
NSArray<FooClass<NSString *> *> *fooAry = [NSArray array];

Soyez prudent avec ces *art.

Les NSArrays génériques peuvent être réalisés en sous-classant NSArrayet en redéfinissant toutes les méthodes fournies avec des méthodes plus restrictives. Par exemple,

- (id)objectAtIndex:(NSUInteger)index

devrait être redéfini en

@interface NSStringArray : NSArray

comme

- (NSString *)objectAtIndex:(NSUInteger)index

pour qu'un NSArray ne contienne que des NSStrings.

La sous-classe créée peut être utilisée comme remplacement instantané et apporte de nombreuses fonctionnalités utiles: avertissements du compilateur, accès aux propriétés, meilleure création de code et achèvement dans Xcode. Toutes ces fonctionnalités sont à la compilation, il n'est pas nécessaire de redéfinir l'implémentation réelle - les méthodes de NSArray peuvent toujours être utilisées.

Il est possible d'automatiser cela et de le réduire à seulement deux instructions, ce qui le rapproche des langages prenant en charge les génériques. J'ai créé une automatisation avec WMGenericCollection , où les modèles sont fournis sous forme de macros de préprocesseur C.

Après avoir importé le fichier d'en-tête contenant la macro, vous pouvez créer un NSArray générique avec deux instructions: une pour l'interface et une pour l'implémentation. Il vous suffit de fournir le type de données que vous souhaitez stocker et les noms de vos sous-classes. WMGenericCollection fournit de tels modèles pour NSArray, NSDictionaryetNSSet , ainsi que leurs homologues mutables.

Un exemple: List<int>pourrait être réalisé par une classe personnalisée appelée NumberArray, qui est créée avec l'instruction suivante:

WMGENERICARRAY_INTERFACE(NSNumber *, // type of the value class
                         // generated class names
                         NumberArray, MutableNumberArray)

Une fois que vous avez créé NumberArray, vous pouvez l'utiliser partout dans votre projet. Il n'a pas la syntaxe de <int>, mais vous pouvez choisir votre propre schéma de dénomination pour les étiqueter comme des classes en tant que modèles.

Jeter un coup d'œil à:

https://github.com/tomersh/Objective-C-Generics

Il semble que ce soit une sorte de générique du pauvre, en réutilisant le mécanisme de vérification du protocole.

Maintenant, les rêves deviennent réalité - il y a des génériques dans Objective-C depuis aujourd'hui (merci, WWDC). Ce n'est pas une blague - sur la page officielle de Swift:

Les nouvelles fonctionnalités de syntaxe vous permettent d'écrire un code plus expressif tout en améliorant la cohérence dans le langage. Les SDK ont utilisé de nouvelles fonctionnalités Objective-C telles que les génériques et l'annotation de nullabilité pour rendre le code Swift encore plus propre et plus sûr. Voici juste un échantillon des améliorations de Swift 2.0.

Et l'image qui le prouve:

Je veux juste sauter ici. J'ai écrit un article de blog ici sur les génériques.

Ce que je veux apporter, c'est que les génériques peuvent être ajoutés à n'importe quelle classe , pas seulement aux classes de collection comme Apple l'indique.

J'ai ensuite ajouté avec succès à une variété de classes car elles fonctionnent exactement de la même manière que les collections d'Apple. c'est à dire. vérification du temps de compilation, complétion du code, permettant la suppression des transtypages, etc.

Prendre plaisir.

Les classes Collections fournies par les frameworks Apple et GNUStep sont semi-génériques en ce qu'elles supposent qu'on leur donne des objets, certains qui sont triables et d'autres qui répondent à certains messages. Pour les primitives comme les floats, les entiers, etc., toute la structure des tableaux C est intacte et peut être utilisée, et il existe des objets wrapper spéciaux pour eux à utiliser dans les classes de collection générales (par exemple NSNumber). De plus, une classe Collection peut être sous-classée (ou spécifiquement modifiée via des catégories) pour accepter des objets de n'importe quel type, mais vous devez écrire vous-même tout le code de gestion de type. Les messages peuvent être envoyés à n'importe quel objet mais doivent renvoyer null si cela ne convient pas à l'objet, ou le message doit être transmis à un objet approprié. Les erreurs de type vrai doivent être détectées au moment de la compilation et non au moment de l'exécution. Au moment de l'exécution, ils doivent être traités ou ignorés. Enfin, Objc fournit des fonctionnalités de réflexion à l'exécution pour gérer les cas délicats et la réponse de message, le type spécifique, et les services peuvent être vérifiés sur un objet avant qu'il ne soit envoyé un message ou placé dans une collection inappropriée. Attention, des bibliothèques et des frameworks disparates adoptent des conventions différentes quant à la façon dont leurs objets se comportent lors de l'envoi de messages pour lesquels ils n'ont pas de réponse de code, donc RTFM. À part les programmes jouets et les builds de débogage, la plupart des programmes ne devraient pas avoir à planter à moins qu'ils ne se trompent vraiment et n'essayent d'écrire de mauvaises données sur la mémoire ou le disque, d'effectuer des opérations illégales (par exemple, diviser par zéro, mais vous pouvez aussi attraper cela), ou accéder ressources système hors limites. Le dynamisme et le temps d'exécution d'Objective-C permettent aux choses d'échouer gracieusement et doivent être intégrés à votre code. (ASTUCE) si vous rencontrez des problèmes de généricité dans vos fonctions, essayez une certaine spécificité. Écrivez les fonctions avec des types spécifiques et laissez le runtime sélectionner (c'est pourquoi ils sont appelés sélecteurs!) La fonction membre appropriée au moment de l'exécution.

Example:
    -(id) sort (id) obj;  // too generic. catches all.
     // better
    -(id) sort: (EasilySortableCollection*) esc;
    -(id) sort: (HardToSortCollection*) hsc; 
    ...
    [Sorter  sort: MyEasyColl];
    [Sorter  sort: MyHardColl];