Pour commencer, les notifications sont envoyés de manière synchrone. Pour que la méthode qui a envoyé la notification puisse continuer son travail, il faut d'abord que toutes les méthodes exécutée par les observeurs aient terminé leur travail.
Parce que la boucle d'events est faite comme ça... Mais l'envoyeur ne va pas savoir quand tel ou tel objet aura terminé. Et encore ce n'est vrai que si on l'on a spécifié "deliverImmediately:YES"
Ensuite, toutes les méthodes de notification SONT des notifications, déléguées ou pas ! Lorsque tu donnes ton objet comme délégué d'une fenêtre par exemple, l'objet NSWindow va regarder toutes les méthodes prenant une NSNotification comme argument et va enregistrer ton objet comme observeur de ses notifications.
Effectivement, ça passe par une vraie notification (ce qui est particulièrement idiot je dirais, mais bon, il y a des choses idiotes dans Cocoa comme partout ). Et dans ce cas ça n'a rien à faire dans la doc en tant que méthodes déléguées.
Et ça doit être nouveau car ce n'était pas le cas avant...
Oui, il s'agit de la dérive dont je parle, le fait que le délégué se coordonne avec son délégué, mais à l'origine c'était surtout pour modifier le comportement de l'objet, d'ailleurs, la plupart des méthodes déléguées (mise à part les notifications qui n'en sont pas !) modifient le comportement de leur délégateur.
Non, ce n'est absolument pas une dérive ça par contre D'ailleurs tu as même cité la phrase de la doc qui le dit (avec le fameux or).
Heureusement que ces objets ne passent pas par les notifications... Quelle perte de temps ça serait ; déjà que les appels dynamiques Obj-C sont lents !
Et pour le "la plupart", il me semble bien que c'est loin d'être vrai (je suis en train de parcourir les objets dans AppKiDo, et c'est plutôt le contraire).
Pour commencer, les notifications sont envoyés de manière synchrone. Pour que la méthode qui a envoyé la notification puisse continuer son travail, il faut d'abord que toutes les méthodes exécutée par les observeurs aient terminé leur travail.
Parce que la boucle d'events est faite comme ça... Mais l'envoyeur ne va pas savoir quand tel ou tel objet aura terminé.
Il ne va pas savoir quel objet reçoit la notification, mais une chose est sûre c'est que tant que tous les objets n'ont pas terminé leur traitement, le notifieur n'a pas l'a main, et ce n'est aucunement une question de boucle d'événement, tout ça ne se passe que dans UNE seule itération : à‰vénement: clic sur le bouton de fermeture de la fenêtre --> La fenêtre envoie windowShouldClose: à son délégué qui retourne YES --> la fenêtre envoie la notification windowWillClose: au notification center --> les observeur traitent la notification (dont le delegate s'il a implémenté la méthode) --> la fenêtre se ferme --> attente du prochain événement.
dans 1234117487:
Et encore ce n'est vrai que si on l'on a spécifié "deliverImmediately:YES"
Là tu confonds avec NSDistirbutedNotificationCenter, qui lui est fait pour envoyer des notifications entre les processi, donc évidemment de manière asynchrone.
dans 1234117487:
Ensuite, toutes les méthodes de notification SONT des notifications, déléguées ou pas ! Lorsque tu donnes ton objet comme délégué d'une fenêtre par exemple, l'objet NSWindow va regarder toutes les méthodes prenant une NSNotification comme argument et va enregistrer ton objet comme observeur de ses notifications.
Effectivement, ça passe par une vraie notification (ce qui est particulièrement idiot je dirais, mais bon, il y a des choses idiotes dans Cocoa comme partout ). Et dans ce cas ça n'a rien à faire dans la doc en tant que méthodes déléguées.
Ce n'est pas idiot, le fait que ce soit signalé comme méthode déléguée nous indique deux choses : 1. la méthode n'est pas implémentée dans la classe elle-même, donc lui envoyer le message ne marchera pas. Et ça n'aurait aucun sens de toutes façons 2. le délégateur enregistrera le nouveau délégué comme observeur de cette notification s'il implémente la méthode.
dans 1234117487:
Et ça doit être nouveau car ce n'était pas le cas avant...
J'aimerais des preuves de ça, et surtout des preuves qui montreraient que vous n'avez pas confondu avec NSDistributedNotificationCenter ou encore les NSThread et autre.
Ce n'est pas idiot, le fait que ce soit signalé comme méthode déléguée nous indique deux choses : 1. la méthode n'est pas implémentée dans la classe elle-même, donc lui envoyer le message ne marchera pas. Et ça n'aurait aucun sens de toutes façons 2. le délégateur enregistrera le nouveau délégué comme observeur de cette notification s'il implémente la méthode.
Ah ben si, c'est complètement idiot Explique moi l'intérêt de passer par un Notification Center, par _CFXNotificationPostNotification, par _nsnode_callback, et du coup de faire 4 appels (sans compter l'abonnement aux notifications...) pour quelque chose qui pourrait être fait en un appel direct ! Ou encore pourquoi le delegate n'aurait pas la priorité par rapport au autres objets abonnés qui ne sont connus ni d'àˆve ni d'Adam.
Et surtout pourquoi quand on poste une notification on doit attendre que tout le monde ait répondu ! Est-ce que le facteur attend devant la porte qu'on lise son courrier avant de partir ? :fouf): Pour moi du coup ça ne mérite pas l'appellation de " notifications " (enfin c'est pas grave, je les utilisais déjà pas à part justement celles des delegates, et heureusement qu'elles attendent pour ce cas précis :P)
dans 1234117487:
Et ça doit être nouveau car ce n'était pas le cas avant...
J'aimerais des preuves de ça, et surtout des preuves qui montreraient que vous n'avez pas confondu avec NSDistributedNotificationCenter ou encore les NSThread et autre.
Sans doute... Comme dit, je ne les utilise jamais autrement que par le delegate.
Ce n'est pas idiot, le fait que ce soit signalé comme méthode déléguée nous indique deux choses : 1. la méthode n'est pas implémentée dans la classe elle-même, donc lui envoyer le message ne marchera pas. Et ça n'aurait aucun sens de toutes façons 2. le délégateur enregistrera le nouveau délégué comme observeur de cette notification s'il implémente la méthode.
Ah ben si, c'est complètement idiot Explique moi l'intérêt de passer par un Notification Center, par _CFXNotificationPostNotification, par _nsnode_callback, et du coup de faire 4 appels (sans compter l'abonnement aux notifications...) pour quelque chose qui pourrait être fait en un appel direct ! Ou encore pourquoi le delegate n'aurait pas la priorité par rapport au autres objets abonnés qui ne sont connus ni d'àˆve ni d'Adam.
Et surtout pourquoi quand on poste une notification on doit attendre que tout le monde ait répondu ! Est-ce que le facteur attend devant la porte qu'on lise son courrier avant de partir ? :fouf): Pour moi du coup ça ne mérite pas l'appellation de " notifications " (enfin c'est pas grave, je les utilisais déjà pas à part justement celles des delegates, et heureusement qu'elles attendent pour ce cas précis :P)
Et ben mon vieux, si tu dois rendre ton application multithread juste pour des notifications t'es pas sorti de la berge, avec toutes les complications (concurrence et tout) que ça implique, t'imagines ?
De plus, ce n'est pas idiot que le notifieur attende que tout le monde ait traité la notification, surtout dans le cas des méthodes de type ...Will...:, ce ne serait pas logique qu'on dise à un objet "cette fenêtre sera fermé" et qu'avant qu'il ait pu récupérer ces affaires pendues de l'autre côté de la fenêtre elle se referme...
Et pour le facteur, dis-toi que c'est une recommandé, et là le facteur attend que la personne ait signé le papier. Et le courrier simple c'est dans le cas de NSDistributedNotificationCenter.
De plus, les delegates n'ont pas forcément la priorité parce que tout simplement ça ne change rien, ils recevront le même objet que les autres, au moment où ils s'y attendent, et étant donné qu'ils ne connaissent pas non plus les autres observeurs ça ne change rien pour eux.
dans 1234118690:
Par exemple, si je prends une classe assez équilibrée avec beaucoup de méthodes déléguées : WebView
80 méthodes déléguées, dont 46 de retour (void) (et donc qui n'influent pas sur la WebView)
J'ai aussi fait mon petit référencement, mais pas sur une classe en particulier parce que ça n'a pas de sens. Certaines classes ont plus besoin de modifier leur propre comportement, et d'autres ont surtout besoin de transmettre les données qu'elles ont reçu...
À l'aide aussi du logiciel AppKiDoo, en sélectionnant Classes with delegates, et en regardant les méthodes indiquées par le point 5 (Delegate methods et non pas ALL delegate methods sinon on les compte deux fois), et en ajoutant les 80 méthodes que tu as compté sur webview et qui n'était pas dans ma liste... Je n'ai bien sûr pas compter les notifications qui ne sont pas des déléguées...
On peut voir 205 méthode retournant une valeur 173 n'en retournant pas. De plus, plus de la moitié des méthodes retournant une valeur existaient déjà avant Mac OS X 10.2, tandis que la plupart des méthodes void sont apparues à partir de 10.2 (WebView étant apparue dans 10.2 et encore qu'avec Safari), ce qui laisse à penser que les délégués sont à l'origine beaucoup plus enclin à modifier le comportement de leur délégateur. Et pour finir, s'il y a un tel nombre de méthodes retournant void c'est surtout grâce à seulement 2 ou 3 classes, en effet, une vingtaine de méthode rien que pour NSXMLParser (apparue en 10.3) et une dizaine pour NSURLConnection... Ces classes en effet ne font que de la récupération de données, et le délégué est là pour les traiter, mais comme elles n'ont rien à faire des données il est logique que leurs méthodes déléguées ne retourne rien.
Et ben mon vieux, si tu dois rendre ton application multithread juste pour des notifications t'es pas sorti de la berge, avec toutes les complications (concurrence et tout) que ça implique, t'imagines ?
De plus, ce n'est pas idiot que le notifieur attende que tout le monde ait traité la notification, surtout dans le cas des méthodes de type ...Will...:, ce ne serait pas logique qu'on dise à un objet "cette fenêtre sera fermé" et qu'avant qu'il ait pu récupérer ces affaires pendues de l'autre côté de la fenêtre elle se referme...
Ben ça aurait été logique que les notifications passent par des events... Pour le coup, ce ne sont pas des notifications, mais de bêtes messages multiples à une liste d'objet. Ce ne sont pas les objets qui viennent demander s'ils ont eu une notification (ce qui aurait été logique pour moi). Un autre exemple de la vie... Quand on se fait notifier de quelque chose par SMS, le service qui a envoyé le SMS va pas attendre savoir si on l'a lu ; il s'en fout. Pour moi une notification c'est ça... Un message dont on se fout de savoir s'il a été reçu ou pas.
Et pour le facteur, dis-toi que c'est une recommandé, et là le facteur attend que la personne ait signé le papier. Et le courrier simple c'est dans le cas de NSDistributedNotificationCenter.
Non justement, il n'attend pas, il laisse une Notification de passage, et il faut se bouger à la posteÂ
À l'aide aussi du logiciel AppKiDoo, en sélectionnant Classes with delegates, et en regardant les méthodes indiquées par le point 5 (Delegate methods et non pas ALL delegate methods sinon on les compte deux fois), et en ajoutant les 80 méthodes que tu as compté sur webview et qui n'était pas dans ma liste... Je n'ai bien sûr pas compter les notifications qui ne sont pas des déléguées...
On peut voir 205 méthode retournant une valeur 173 n'en retournant pas. De plus, plus de la moitié des méthodes retournant une valeur existaient déjà avant Mac OS X 10.2, tandis que la plupart des méthodes void sont apparues à partir de 10.2 (WebView étant apparue dans 10.2 et encore qu'avec Safari), ce qui laisse à penser que les délégués sont à l'origine beaucoup plus enclin à modifier le comportement de leur délégateur. Et pour finir, s'il y a un tel nombre de méthodes retournant void c'est surtout grâce à seulement 2 ou 3 classes, en effet, une vingtaine de méthode rien que pour NSXMLParser (apparue en 10.3) et une dizaine pour NSURLConnection... Ces classes en effet ne font que de la récupération de données, et le délégué est là pour les traiter, mais comme elles n'ont rien à faire des données il est logique que leurs méthodes déléguées ne retourne rien.
Là c'est de la mauvaise foi Pour le coup tu as bien dû te rendre compte que ne pas jouer sur la vie de son appelant n'est pas un comportement marginal, mais bien standard :fouf): Quel rapport avec 10.2, 10.3 etc ? Apple n'a jamais considéré que les delegate devaient être réservés à l'information de l'appelant :P Effectivement, il y a des classes qui les utilisent plus pour ça (les contrôles et vues, ce qui est normal... et comme y en a beaucoup...), et d'autres classes c'est le contraire (les parser).
C'est pour ça que j'ai pris l'exemple de WebView qui n'est ni un contrôle, ni un parser et du coup joue sur les deux plans.
Les méthodes déléguées sont celles dont le premier argument est le délégateur, ce qui exclu les notifications, les méthodes en "-(void)...Will...:(NSNotification*)notification", comme l'indique leur premier et seul paramètre, sont des notifications, mais elles sont signalées comme méthodes déléguées tout simplement parce que, pour toute notification, le délégateur envoie la notification directement à son délégué sans passer par le notification center ; un délégué, et c'est dit explicitement dans la doc, est d'office observeur des notifications envoyées par le délégateur, et donc les notifications, pour des raisons de performance, sont aussi transformées en méthode déléguées, mais elles restent des notifications car leur argument est une NSNotification et non pas l'objet délégant.
Tiens, je viens de tiquer, je ne comprends pas ce que tu as dit là du coup... Même pour le delegate, le délégateur utilise bien le notification center (je l'ai vu dans la pile d'appel avec un point d'arrêt). Et effectivement, niveau performances comme je l'ai dit dans un post au dessus (3 appels de plus avec derrière des fonctions pas forcément anodines, au lieu d'un direct), ben... c'est pas malin je trouve. ???
Ben la synthèse c'est pas compliqué :P - Delegate = Callback (traitement délégué qui influe ou non l'appelant) - Notifications = messages distribués à plusieurs objets Et à savoir (merci psychoh13) que les "delegate methods" qui ont pour argument "NSNotification*" ne sont pas de vraies-fausses "delegate methods" mais de fausses-vraies Notifications ; et que les notifications sont synchrones.
Réponses
Parce que la boucle d'events est faite comme ça... Mais l'envoyeur ne va pas savoir quand tel ou tel objet aura terminé.
Et encore ce n'est vrai que si on l'on a spécifié "deliverImmediately:YES"
Effectivement, ça passe par une vraie notification (ce qui est particulièrement idiot je dirais, mais bon, il y a des choses idiotes dans Cocoa comme partout
Et dans ce cas ça n'a rien à faire dans la doc en tant que méthodes déléguées.
Et ça doit être nouveau car ce n'était pas le cas avant...
Non, ce n'est absolument pas une dérive ça par contre
D'ailleurs tu as même cité la phrase de la doc qui le dit (avec le fameux or).
Heureusement que ces objets ne passent pas par les notifications... Quelle perte de temps ça serait ; déjà que les appels dynamiques Obj-C sont lents !
Et pour le "la plupart", il me semble bien que c'est loin d'être vrai (je suis en train de parcourir les objets dans AppKiDo, et c'est plutôt le contraire).
Il ne va pas savoir quel objet reçoit la notification, mais une chose est sûre c'est que tant que tous les objets n'ont pas terminé leur traitement, le notifieur n'a pas l'a main, et ce n'est aucunement une question de boucle d'événement, tout ça ne se passe que dans UNE seule itération :
à‰vénement: clic sur le bouton de fermeture de la fenêtre --> La fenêtre envoie windowShouldClose: à son délégué qui retourne YES --> la fenêtre envoie la notification windowWillClose: au notification center --> les observeur traitent la notification (dont le delegate s'il a implémenté la méthode) --> la fenêtre se ferme --> attente du prochain événement.
Là tu confonds avec NSDistirbutedNotificationCenter, qui lui est fait pour envoyer des notifications entre les processi, donc évidemment de manière asynchrone.
Ce n'est pas idiot, le fait que ce soit signalé comme méthode déléguée nous indique deux choses :
1. la méthode n'est pas implémentée dans la classe elle-même, donc lui envoyer le message ne marchera pas. Et ça n'aurait aucun sens de toutes façons
2. le délégateur enregistrera le nouveau délégué comme observeur de cette notification s'il implémente la méthode.
J'aimerais des preuves de ça, et surtout des preuves qui montreraient que vous n'avez pas confondu avec NSDistributedNotificationCenter ou encore les NSThread et autre.
80 méthodes déléguées, dont 46 de retour (void) (et donc qui n'influent pas sur la WebView)
Ah ben si, c'est complètement idiot
Explique moi l'intérêt de passer par un Notification Center, par _CFXNotificationPostNotification, par _nsnode_callback, et du coup de faire 4 appels (sans compter l'abonnement aux notifications...) pour quelque chose qui pourrait être fait en un appel direct !
Ou encore pourquoi le delegate n'aurait pas la priorité par rapport au autres objets abonnés qui ne sont connus ni d'àˆve ni d'Adam.
Et surtout pourquoi quand on poste une notification on doit attendre que tout le monde ait répondu !
Est-ce que le facteur attend devant la porte qu'on lise son courrier avant de partir ? :fouf):
Pour moi du coup ça ne mérite pas l'appellation de " notifications " (enfin c'est pas grave, je les utilisais déjà pas à part justement celles des delegates, et heureusement qu'elles attendent pour ce cas précis :P)
Sans doute... Comme dit, je ne les utilise jamais autrement que par le delegate.
Et ben mon vieux, si tu dois rendre ton application multithread juste pour des notifications t'es pas sorti de la berge, avec toutes les complications (concurrence et tout) que ça implique, t'imagines ?
De plus, ce n'est pas idiot que le notifieur attende que tout le monde ait traité la notification, surtout dans le cas des méthodes de type ...Will...:, ce ne serait pas logique qu'on dise à un objet "cette fenêtre sera fermé" et qu'avant qu'il ait pu récupérer ces affaires pendues de l'autre côté de la fenêtre elle se referme...
Et pour le facteur, dis-toi que c'est une recommandé, et là le facteur attend que la personne ait signé le papier.
De plus, les delegates n'ont pas forcément la priorité parce que tout simplement ça ne change rien, ils recevront le même objet que les autres, au moment où ils s'y attendent, et étant donné qu'ils ne connaissent pas non plus les autres observeurs ça ne change rien pour eux.
J'ai aussi fait mon petit référencement, mais pas sur une classe en particulier parce que ça n'a pas de sens. Certaines classes ont plus besoin de modifier leur propre comportement, et d'autres ont surtout besoin de transmettre les données qu'elles ont reçu...
À l'aide aussi du logiciel AppKiDoo, en sélectionnant Classes with delegates, et en regardant les méthodes indiquées par le point 5 (Delegate methods et non pas ALL delegate methods sinon on les compte deux fois), et en ajoutant les 80 méthodes que tu as compté sur webview et qui n'était pas dans ma liste... Je n'ai bien sûr pas compter les notifications qui ne sont pas des déléguées...
On peut voir 205 méthode retournant une valeur 173 n'en retournant pas.
De plus, plus de la moitié des méthodes retournant une valeur existaient déjà avant Mac OS X 10.2, tandis que la plupart des méthodes void sont apparues à partir de 10.2 (WebView étant apparue dans 10.2 et encore qu'avec Safari), ce qui laisse à penser que les délégués sont à l'origine beaucoup plus enclin à modifier le comportement de leur délégateur.
Et pour finir, s'il y a un tel nombre de méthodes retournant void c'est surtout grâce à seulement 2 ou 3 classes, en effet, une vingtaine de méthode rien que pour NSXMLParser (apparue en 10.3) et une dizaine pour NSURLConnection... Ces classes en effet ne font que de la récupération de données, et le délégué est là pour les traiter, mais comme elles n'ont rien à faire des données il est logique que leurs méthodes déléguées ne retourne rien.
Ben ça aurait été logique que les notifications passent par des events... Pour le coup, ce ne sont pas des notifications, mais de bêtes messages multiples à une liste d'objet.
Ce ne sont pas les objets qui viennent demander s'ils ont eu une notification (ce qui aurait été logique pour moi).
Un autre exemple de la vie... Quand on se fait notifier de quelque chose par SMS, le service qui a envoyé le SMS va pas attendre savoir si on l'a lu ; il s'en fout.
Pour moi une notification c'est ça... Un message dont on se fout de savoir s'il a été reçu ou pas.
Non justement, il n'attend pas, il laisse une Notification de passage, et il faut se bouger à la posteÂ
Là c'est de la mauvaise foi
Pour le coup tu as bien dû te rendre compte que ne pas jouer sur la vie de son appelant n'est pas un comportement marginal, mais bien standard :fouf):
Quel rapport avec 10.2, 10.3 etc ?
Apple n'a jamais considéré que les delegate devaient être réservés à l'information de l'appelant :P
Effectivement, il y a des classes qui les utilisent plus pour ça (les contrôles et vues, ce qui est normal... et comme y en a beaucoup...), et d'autres classes c'est le contraire (les parser).
C'est pour ça que j'ai pris l'exemple de WebView qui n'est ni un contrôle, ni un parser et du coup joue sur les deux plans.
Tiens, je viens de tiquer, je ne comprends pas ce que tu as dit là du coup... Même pour le delegate, le délégateur utilise bien le notification center (je l'ai vu dans la pile d'appel avec un point d'arrêt).
Et effectivement, niveau performances comme je l'ai dit dans un post au dessus (3 appels de plus avec derrière des fonctions pas forcément anodines, au lieu d'un direct), ben... c'est pas malin je trouve. ???
- Delegate = Callback (traitement délégué qui influe ou non l'appelant)
- Notifications = messages distribués à plusieurs objets
Et à savoir (merci psychoh13) que les "delegate methods" qui ont pour argument "NSNotification*" ne sont pas de vraies-fausses "delegate methods" mais de fausses-vraies Notifications ; et que les notifications sont synchrones.
Les delegates c'est l'adaptation à la POO de ça :
http://fr.wikipedia.org/wiki/Fonction_de_rappel