Venant de l'objectif-C, je me demande si c'est une bonne pratique de faire descendre ses propres classes de NSObject. Notamment pour bénéficier du KVC ?
Perso je vois pas trop l'intérêt de le faire systématiquement. Je ne le ferai que si c'est vraiment nécessaire.
En pratique, je crois que depuis que je fais du Swift je n'ai jamais créé une classe qui hérite directement de NSObject. Des custom UIView ou UITableViewCell par exemple, oui. Mais NSObject, non. D'autant que quitte à faire du Swift, autant utiliser au maximum ses capacités statiques (validation à la compilation, etc) et éviter le KVC qui est super-dynamically-typed par définition et qui ne permet aucune vérification de type (si tu fais une erreur ça crachera à l'exécution et pas à la compilation), alors que Swift est plutôt pensé pour être statically-typed au possible. Utiliser KVC signifie utiliser le mécanisme de message-dispatch et le runtime ObjC sous le capot au lieu de profiter du Swift et de ses optimisations à la compilation car il connaà®t tous les types d'avance. Je ne renie pas le KVC, c'était pratique parfois en ObjC, mais même si c'est toujours possible en Swift vu que Swift permet d'utiliser le Runtime ObjC, c'est quand même bien moins courant dans le monde de Swift de voir du KVC.
Merci pour vos réponses. Je vais tenter de faire autrement. L'idée est de rendre le plus réutilisable le controller en limitant les liens avec le model...
Je l'utilise rarement en Swift aussi. Les rares fois où j'ai pu l'utiliser c'était par exemple pour me servir de NSCoding. Je suis d'avis d'utiliser que ce dont on a besoin pour une question de clarté.
Le KVC comme le KVO je pense sont beaucoup moins utilisé en Swift je pense comme l'a expliqué Aligator bien que des fois on n'y échappe pas comme lorsqu'on souhaite utiliser CoreAnimation.
Merci pour vos réponses. Je vais tenter de faire autrement. L'idée est de rendre le plus réutilisable le controller en limitant les liens avec le model...
Dans ce cas il fait penser Protocol Oriented Programming. Ce qui est d'ailleurs un concept au coeur de Swift justement.
Pour les binding, tu peux toujours utiliser un objet "façade" qui dérive de NSObject pour faire le pont.
D'autre part, en utilisant :
-des fonctions generics
-un protocol
-la reflection
-une target spécifique dans Xcode et un scheme chiadé,
on doit pouvoir générer en précompilation des extensions de classes qui contiennent des méthodes generics setValueForKey et valueForKey qui feront le mapping entre les noms en texte et les appels de propriétés correspondantes.
Bon ce serait plus pratique que le compilateur le fasse.
Sur la liste swift-evolution, on trouve des propositions pour implementer KVC dans le language swift. Dans sa réponse, Lattner (le big boss) dit que tout cela est bien sympathique et encourage à lancer des idées mais que le KVC ne verra le jour que dans swift 4 au mieux. Sachant que swift 3 est prévu pour dans un an.
Réponses
En pratique, je crois que depuis que je fais du Swift je n'ai jamais créé une classe qui hérite directement de NSObject. Des custom UIView ou UITableViewCell par exemple, oui. Mais NSObject, non.
D'autant que quitte à faire du Swift, autant utiliser au maximum ses capacités statiques (validation à la compilation, etc) et éviter le KVC qui est super-dynamically-typed par définition et qui ne permet aucune vérification de type (si tu fais une erreur ça crachera à l'exécution et pas à la compilation), alors que Swift est plutôt pensé pour être statically-typed au possible.
Utiliser KVC signifie utiliser le mécanisme de message-dispatch et le runtime ObjC sous le capot au lieu de profiter du Swift et de ses optimisations à la compilation car il connaà®t tous les types d'avance. Je ne renie pas le KVC, c'était pratique parfois en ObjC, mais même si c'est toujours possible en Swift vu que Swift permet d'utiliser le Runtime ObjC, c'est quand même bien moins courant dans le monde de Swift de voir du KVC.
Merci pour vos réponses. Je vais tenter de faire autrement. L'idée est de rendre le plus réutilisable le controller en limitant les liens avec le model...
Je l'utilise rarement en Swift aussi. Les rares fois où j'ai pu l'utiliser c'était par exemple pour me servir de NSCoding. Je suis d'avis d'utiliser que ce dont on a besoin pour une question de clarté.
Le KVC comme le KVO je pense sont beaucoup moins utilisé en Swift je pense comme l'a expliqué Aligator bien que des fois on n'y échappe pas comme lorsqu'on souhaite utiliser CoreAnimation.
Après si on dev sur OSX et qu'on utilise les bindings, le KVC n'est pas une option.
Il serait temps qu'ils fassent un truc plus Swift-friendly d'ailleurs...
D'autre part, en utilisant :
-des fonctions generics
-un protocol
-la reflection
-une target spécifique dans Xcode et un scheme chiadé,
on doit pouvoir générer en précompilation des extensions de classes qui contiennent des méthodes generics setValueForKey et valueForKey qui feront le mapping entre les noms en texte et les appels de propriétés correspondantes.
Bon ce serait plus pratique que le compilateur le fasse.
Sur la liste swift-evolution, on trouve des propositions pour implementer KVC dans le language swift. Dans sa réponse, Lattner (le big boss) dit que tout cela est bien sympathique et encourage à lancer des idées mais que le KVC ne verra le jour que dans swift 4 au mieux. Sachant que swift 3 est prévu pour dans un an.