KVO, Le saviez vous ?
JegnuX
Membre
Salut à tous !
L'autre jour, quand j'effectuais la modification conseillée par Yoann sur ma classe JXMagicObject (http://forum.cocoacafe.fr/topic/9292-jxmagicobject-mapping-facile-entre-dictionnaires-et-properties/page__fromsearch__1) j'ai découvert quelque chose au sujet de KVO.
En effet donc, comme me la suggéré Yoann, j'ai déplacé le setupMappings dans le +initialize de la classe.
Sauf que je me suis rendu compte que ce +initialize était appelé plus souvent que prévu. Un petit log de [self class] (et de la superclass) et je vois ça :
Vous l'aurez devinez, ce qui m'a interpellé c'est le préfixe NSKVONotifying_
Donc en fait quand on fait un addObserver:... sur un objet, ça créé une sous-classe, et le runtime se charge de changer la superclass de tout les objets à la volée.
Un peu d'introspection sur cette classe et je vois que les seules méthodes implémentées sont
+class : probablement pour retourner la classe sans le préfixe
les setters des keyPath observé
et le dealloc
Bon alors j'ai pas vérifié, mais je pense que ça ne fait ça que pour les properties @synthesize.
Mais du coup, pourquoi ?
Le seul intérêt que je vois à faire ça, c'est pour ne faire les -willChangeValueForKey: et -didChangeValueForKey: que si cela est nécessaire, c'est à dire que si il y a un observer sur cette key. Et ainsi, par défaut un setter généré par @synthesize n'enverra pas ces messages.
Voyez vous d'autres raisons ? Et pensez vous que ça optimise vraiment de faire cela ?
En tout cas je trouve ça intéressant comme pratique
/smile.png' class='bbc_emoticon' alt=':)' />
L'autre jour, quand j'effectuais la modification conseillée par Yoann sur ma classe JXMagicObject (http://forum.cocoacafe.fr/topic/9292-jxmagicobject-mapping-facile-entre-dictionnaires-et-properties/page__fromsearch__1) j'ai découvert quelque chose au sujet de KVO.
En effet donc, comme me la suggéré Yoann, j'ai déplacé le setupMappings dans le +initialize de la classe.
Sauf que je me suis rendu compte que ce +initialize était appelé plus souvent que prévu. Un petit log de [self class] (et de la superclass) et je vois ça :
JXMagicObject : NSObject<br />
JXUser : JXMagicObject<br />
NSKVONotifying_JXUser : JXUser<br />
JXGithubAccount : JXMagicObject<br />
NSKVONotifying_JXGithubAccount : JXGithubAccount<br />Vous l'aurez devinez, ce qui m'a interpellé c'est le préfixe NSKVONotifying_
Donc en fait quand on fait un addObserver:... sur un objet, ça créé une sous-classe, et le runtime se charge de changer la superclass de tout les objets à la volée.
Un peu d'introspection sur cette classe et je vois que les seules méthodes implémentées sont
+class : probablement pour retourner la classe sans le préfixe
les setters des keyPath observé
et le dealloc
Bon alors j'ai pas vérifié, mais je pense que ça ne fait ça que pour les properties @synthesize.
Mais du coup, pourquoi ?
Le seul intérêt que je vois à faire ça, c'est pour ne faire les -willChangeValueForKey: et -didChangeValueForKey: que si cela est nécessaire, c'est à dire que si il y a un observer sur cette key. Et ainsi, par défaut un setter généré par @synthesize n'enverra pas ces messages.
Voyez vous d'autres raisons ? Et pensez vous que ça optimise vraiment de faire cela ?
En tout cas je trouve ça intéressant comme pratique
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
http://mikeash.com/pyblog/friday-qa-2009-01-23.html
D'ailleurs c'est pas la première fois que je tombe sur des articles intéressants de ce Mike Ash (c'est un des gars de Plausible Labs, au cas où vous ne connaà®triez pas ils font des classes assez sympas et poussées, genre PLWeakCompatibility pour supporter les Zeroing Weak References sous iOS<5.0, etc), je vous en conseille la lecture. Il a des articles dans ses "Friday Q&As" qui expliquent comment sont implémentées certaines choses par Apple, c'est tjs intéressant.