›

Programmation Cocoa sous MacOsX 3ème édition en Français est sorti

GercofisGercofis Membre
06:36 modifié dans Actualités #1
Ben ! dans le titre ( dire que j'allais acheter l'original... )

Bref très bien fait ...

J'avoue ne pas capter la partie supérieure de la page 60, au cas ou ?
«1

Réponses

  • AliGatorAliGator Membre, Modérateur
    06:36 modifié #2
    Heu oui on (heu... même... toi, d'ailleurs :)) avant déjà  posté à  ce sujet ici non ?  ;D
  • schlumschlum Membre
    06:36 modifié #3
    C'est quoi le problème avec la page 60 ? ça parle juste des règles avec les constructeurs "init"  ???
  • GercofisGercofis Membre
    06:36 modifié #4
    Juste la partie en dessous.

    - (id)init<br />{<br />[self dealloc];<br />@throw.....<br />return nil ;<br />}<br />

  • schlumschlum Membre
    06:36 modifié #5
    En Objective-C, la gestion des constructeurs est un peu foireuse... Comme NSObject répond à  "init", toute classe répond à  "init". Il veut une classe qu'on ne peut initialiser qu'avec un argument, donc il interdit l'utilisation du constructeur "init" en envoyant une exception.
  • ChachaChacha Membre
    06:36 modifié #6
    dans 1228533282:

    En Objective-C, la gestion des constructeurs est un peu foireuse...

    Moi qui trouvais que c'était beau à  pleurer (constructeurs virtuels, etc...) !
    Plus sérieusement, Schlum, c'est quoi que tu trouves foireux dans les constructeurs en Objective-C ?

    +
    Chacha
  • GercofisGercofis Membre
    06:36 modifié #7
    dans 1228512226:

    Heu oui on (heu... même... toi, d'ailleurs :)) avant déjà  posté à  ce sujet ici non ?  ;D
    Il me semblait, mais bon je n'ai pas retrouvé, tu me dis ou c'est et on l'enlève
  • schlumschlum Membre
    06:36 modifié #8
    dans 1228550850:

    dans 1228533282:

    En Objective-C, la gestion des constructeurs est un peu foireuse...

    Moi qui trouvais que c'était beau à  pleurer (constructeurs virtuels, etc...) !
    Plus sérieusement, Schlum, c'est quoi que tu trouves foireux dans les constructeurs en Objective-C ?

    +
    Chacha


    En C++ les constructeurs et destructeurs ne s'héritent pas ; il ne renvoient pas non plus de référence (ils ne renvoient rien en fait), et le compilateur envoie un warning si certains composants de l'objet ne sont pas initialisés ; quant au constructeur par défaut, il met tout à  0.
    Toutes ces choses sont d'une logique foudroyante, mais ne sont pas faites en Objective-C  ;) En gros on s'aperçoit des m***** au moment de l'exécution et pas de la compilation !
  • ChachaChacha Membre
    06:36 modifié #9
    dans 1228571824:

    En C++ les constructeurs et destructeurs ne s'héritent pas ; il ne renvoient pas non plus de référence (ils ne renvoient rien en fait),

    Ben oui, mais en C++, un échec de construction est pénible à  gérer, alors que la séparation alloc/init est fort pratique. Exemple : reproduire le protocole NSCoding en C++ est pénible.


    et le compilateur envoie un warning si certains composants de l'objet ne sont pas initialisés ; quant au constructeur par défaut, il met tout à  0.

    En C++, le constructeur par défaut ne met *pas* tout à  zéro, ce n'est pas dans le standard ! Par contre, en Objective-C, c'est le cas (http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_4_section_2.html)


    et le compilateur envoie un warning si certains composants de l'objet ne sont pas initialisés

    à  l'usage, le switch "check effective C++ violations" est plutôt lourdingue, je trouve... Surtout quand on encapsule des objets.

    Question de goût, je suppose...

    +
    Chacha
  • psychoh13psychoh13 Mothership Developer Membre
    06:36 modifié #10
    Le coup du dealloc dans le init c'est à  banir, je suis choqué qu'Aaron ait écrit ça !

    Et les init en ObjC sont simples ! Il suffit de s'accorder sur les règles : un seul initialisateur désigné qui appel l'initialiseur désigné de la super-classe, et la surcharge de l'initialiseur désigné de la super-classe. Et avec ça quelque soit le nombre de constructeur de la super-classe, ils seront tous gérés.
  • GercofisGercofis Membre
    décembre 2008 modifié #11
    J'espérais plus une explication...

    Mais bon ça fait plaisir...

    Mon anglais et mes compétences étant limites...
    Peut-être vérifier sur la version Anglaise ?
    Peut-être lui écrire : aaron@bignerdranch.com

    Je demande a l'éditeur l'adresse pour les coquilles, ou petites erreurs, par là  même je demande les émails des traducteurs, bien que ce code a pas dû être modifié...
  • schlumschlum Membre
    décembre 2008 modifié #12
    dans 1228656203:


    et le compilateur envoie un warning si certains composants de l'objet ne sont pas initialisés ; quant au constructeur par défaut, il met tout à  0.

    En C++, le constructeur par défaut ne met *pas* tout à  zéro, ce n'est pas dans le standard ! Par contre, en Objective-C, c'est le cas (http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_4_section_2.html)


    Je me suis emmêlé les pinceaux ; je voulais dire que s'il y avait un autre constructeur défini, et pas de constructeur par défaut défini explicitement ; on ne pouvait appeler le constructeur par défaut, même s'il est défini dans la classe mère (et ça pète à  la compilation).
    Pour la remise à  0, effectivement, ce n'est pas standard... gcc le fait pour un objet seul, et pas pour un tableau d'objets.

    En fait il n'y a pas de constructeurs en Objective-C, juste des allocations ; les constructeurs sont des méthodes comme les autres et sont " héritables " (ce qui est un non-sens).
  • schlumschlum Membre
    06:36 modifié #13
    dans 1228656203:

    à  l'usage, le switch "check effective C++ violations" est plutôt lourdingue, je trouve... Surtout quand on encapsule des objets.

    Question de goût, je suppose...

    +
    Chacha


    ça oblige à  avoir des constructions d'objets très propres et rigoureuses, c'est sûr  :P
  • schlumschlum Membre
    06:36 modifié #14
    dans 1228657153:

    Le coup du dealloc dans le init c'est à  banir, je suis choqué qu'Aaron ait écrit ça !

    Et les init en ObjC sont simples ! Il suffit de s'accorder sur les règles : un seul initialisateur désigné qui appel l'initialiseur désigné de la super-classe, et la surcharge de l'initialiseur désigné de la super-classe. Et avec ça quelque soit le nombre de constructeur de la super-classe, ils seront tous gérés.


    Pourquoi à  bannir ? Il désalloue l'objet et renvoie "nil" (ce qui ne sert à  rien puisqu'il y a un, throw), donc se comporte comme si l'allocation avait échouée.
    S'il ne faisait pas ça, imaginons qu'on ait un @try au-dessus, on ne saurait pas si la mémoire a été effectivement allouée ou non !
    (mais c'est clair que ça montre les limites du système de " construction d'objets " en Obj-C).
  • GercofisGercofis Membre
    06:36 modifié #15
    Ben en fait ce que je ne pige pas de trop c'est le pourquoi du dealloc...
  • ChachaChacha Membre
    06:36 modifié #16
    dans 1228669386:

    ça oblige à  avoir des constructions d'objets très propres et rigoureuses, c'est sûr  :P

    Je n'irai jamais assez dans ton sens : les warnings sont nos amis.
    par contre, j'ai quand même du mal avec -Weffc++. Exemple :

    class A
    {
     public:
       A() {} //warning, il faut mettre A():s() {}
     private:
       std::string s;
    };




    Pourquoi à  bannir ? Il désalloue l'objet et renvoie "nil"

    J'aurais plutôt eu tendance à  utiliser [self autorelease] en cas de construction foireuse, et renvoyer nil. Je trouve ça assez propre, et ça simplifie beaucoup le code, en fait, car en amont, pas besoin d'alourdir avec des @try. Pouvoir envoyer des messages à  nil diminue beaucoup le nombre de tests ! Je m'explique :

    A* a = [[A alloc] initWithBlopPowShebam] ...peut revonyer nil
    [a plif];
    ....
    B* b = [a plof];
    if (!b) //un seul test, que "a" soit nil ou que [a plof] ait renvoyé nil.
     NSLog(@kaput)




    les constructeurs sont des méthodes comme les autres et sont " héritables " (ce qui est un non-sens).

    Ce n'est pas un "non sens", ça permet d'avoir des constructeurs virtuels !


    je voulais dire que s'il y avait un autre constructeur défini, et pas de constructeur par défaut défini explicitement ; on ne pouvait appeler le constructeur par défaut, même s'il est défini dans la classe mère (et ça pète à  la compilation).

    Maintenant, je crois quand même que je comprends ton avis : au moins en C++, si ça compile pas, on sait pourquoi. Alors qu'en Objective-C, si ça marche pas, on cherche un moment pour savoir d'où ça vient. La rigueur du C++ est un atout, la souplesse de l'Objective-C une source de problèmes autant qu'elle est pratique. Dur dur d'avoir le meilleur des deux !

    +
    Chacha
  • schlumschlum Membre
    06:36 modifié #17
    dans 1228672202:

    Ben en fait ce que je ne pige pas de trop c'est le pourquoi du dealloc...


    Pour ne pas laisser la mémoire dans un état incertain au niveau du premier @try rencontré.
  • GercofisGercofis Membre
    06:36 modifié #18
    Simplement me confirmer si j'ai bien compris...

    Vu qu'il est précisé que si on code sa propre fonction init avec un paramètre, on redéfinie la fonction init comme indiquée pour le cas ou on diffuse sa classe.

    Si l'utilisateur n'en tient pas compte ça dealloc et envoie un message sur la console pour signaler, une alerte eu probablement été un +...

    J'ai bon ?

  • schlumschlum Membre
    06:36 modifié #19
    C'est pire que ça... ça envoie une exception.
    Si elle n'est pas "catchée" ou à  l'intérieur d'un événement traité par la boucle d'événements, ça fait planter tout le programme.

    Si c'est à  l'intérieur d'un événement (IBAction par exemple), ça l'annihile complètement.
  • GercofisGercofis Membre
    06:36 modifié #20
    Pour info la relecture technique est réalisé pas Fabien Schwob
    et son site est la :http://www.cocoa.fr/
    En cas de questions...
  • AntilogAntilog Membre
    06:36 modifié #21
    Tiens!!

    Il y a un lien sur un site fameux sur la page:
    http://www.pearson.fr/livre/?GCOI=27440100726260

    Rubrique compléments

    <3 :p :p :fouf):
  • GercofisGercofis Membre
    06:36 modifié #22
    Même que si tu vas en bas et que tu lis l'avis d'un lecteur d'Amazon ça pourrais bien être moi...
  • GercofisGercofis Membre
    06:36 modifié #23
    Page 107 la 3ème strophe commence par:
    Hormis l&#39;outlet datasource, une vue tableau possède également une outlet delegate etc


    Une explication ? je pensais que l'outlet était réservé au objet IB pour être connecté a la classe...
    Le terme Outlet delegate me choque aussi...

    vos avis seront les bienvenus...
  • psychoh13psychoh13 Mothership Developer Membre
    06:36 modifié #24
    Un outlet est une variable d'instance reconnue par Interface Builder et qui permet de lier les références graphiquement.
    Pour qu'une ivar deviennent un outlet, il faut soit que IBOutlet soit écrit juste avant le nom du type de l'ivar, ou alors que l'ivar soit de type "id".
    Ce qu'il fait que "delegate" et "datasource" sont des outlets, la preuve en est c'est que tu peux les faire référencer des objets graphiquement via IB.
  • AliGatorAliGator Membre, Modérateur
    06:36 modifié #25
    Oui ton delegate est une variable d'instance comme une autre, mais comme elle a en plus le mot clé "IBOutlet" au début de sa déclaration (en plus de la déclaration normale), ça rajoute juste le fait qu'elle est visible dans IB, donc que tu peux connecter cet IBOutlet directement depuis IB. Mais si tu veux affecter le delegate par code, tu peux aussi, tu as le choix.
    Après tout, des IBOutlets ne sont rien d'autre que des variables d'instances comme les autres (si ce n'est qu'elles sont en plus visibles dans IB) donc tu peux les utiliser comme les autres variables d'instance (ou préférer IB)
  • psychoh13psychoh13 Mothership Developer Membre
    06:36 modifié #26
    dans 1228932959:

    Oui ton delegate est une variable d'instance comme une autre, mais comme elle a en plus le mot clé "IBOutlet" au début de sa déclaration (en plus de la déclaration normale)


    J'aimerais bien que tu me trouves ne serait-ce qu'une seule classe qui définisse un delegate ou un datasource en tant qu'IBOutlet...

    Personnellement, je n'ai jamais vu de déclaration comme ça : IBOutlet id _delegate ou IBOutlet id _dataSource...
  • schlumschlum Membre
    06:36 modifié #27
    dans 1228932804:

    Un outlet est une variable d'instance reconnue par Interface Builder et qui permet de lier les références graphiquement.
    Pour qu'une ivar deviennent un outlet, il faut soit que IBOutlet soit écrit juste avant le nom du type de l'ivar, ou alors que l'ivar soit de type "id".
    Ce qu'il fait que "delegate" et "datasource" sont des outlets, la preuve en est c'est que tu peux les faire référencer des objets graphiquement via IB.


    AMHA c'est plus compliqué que ça...
    Par exemple :

    @interface NSTableView : NSControl &lt;NSUserInterfaceValidations&gt;<br />{<br />&nbsp; &nbsp; /*All instance variables are private*/<br />&nbsp; &nbsp; NSTableHeaderView	*_headerView;<br />&nbsp; &nbsp; NSView		*_cornerView;<br />&nbsp; &nbsp; NSMutableArray&nbsp; &nbsp;  	*_tableColumns;<br />&nbsp; &nbsp; NSCell		*_editingCell;<br />&nbsp; &nbsp; id			_delegate;<br />&nbsp; &nbsp; id			_dataSource;<br />&nbsp; &nbsp; NSSize		_intercellSpacing;<br />&nbsp; &nbsp; CGFloat		_rowHeight;<br />&nbsp; &nbsp; NSInteger		_lastSelectedColumn;<br />&nbsp; &nbsp; NSInteger		_lastSelectedRow;<br />&nbsp; &nbsp; NSInteger		_editingRow;<br />&nbsp; &nbsp; NSInteger		_editingColumn;<br />&nbsp; &nbsp; NSMutableIndexSet	*_selectedColumns;<br />&nbsp; &nbsp; NSMutableIndexSet	*_selectedRows;<br />&nbsp; &nbsp; NSImage		*_bodyDragImage;<br />&nbsp; &nbsp; NSColor		*_backgroundColor;<br />&nbsp; &nbsp; NSColor		*_gridColor;<br />&nbsp; &nbsp; CGFloat		_dragYPos;<br />&nbsp; &nbsp; id			_target;<br />&nbsp; &nbsp; SEL&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  _action;<br />&nbsp; &nbsp; SEL&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  _doubleAction;<br />&nbsp; &nbsp; NSRect		_rectOfLastColumn;<br />&nbsp; &nbsp; NSInteger		_lastCachedRectColumn;<br />&nbsp; &nbsp; NSRect		_rectOfLastRow;<br />&nbsp; &nbsp; NSInteger		_lastCachedRectRow;<br />&nbsp; &nbsp; _TvFlags&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; _tvFlags;<br />&nbsp; &nbsp; id&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; _reserved;<br />}


    Déjà  dans IB, on ne voit pas "_delegate" mais "delegate" et pas "_dataSource", mais "dataSource"...
    Et ensuite, on ne voit pas "_reserved"  :o
  • psychoh13psychoh13 Mothership Developer Membre
    06:36 modifié #28
    Oui mais IB fait aussi beaucoup de manipulations de noms... TU remarques si tu utilises les bindings que IB fait mumuse avec tes noms pour les rendre lisible, genre PSYTournamentManagedObject il va te l'afficher en Tournament Managed Object...
    Alors peut-être que _delegate et _datasource ont un traitement de faveur, mais je peux te garantir que n'importe quelle variable d'instance de type id dont le nom ne commence pas par _ va être reconnue par IB, avec ou sans IBOutlet, et c'est écrit dans la norme.

    Et en fait non, delegate et datasource n'ont pas de réel traitement de faveur, en fait s'ils sont visibles alors qu'ils ont l'underscore c'est sûrement parce que ces objets sont configurés comme ça dans les plugins IB.
  • AliGatorAliGator Membre, Modérateur
    06:36 modifié #29
    Même sans underscore avant d'ailleurs
    Il doit y avoir des noms de variables d'instance réservés qui sont automatiquement IBOutlets

    Il suffit de mettre [tt]id delegate[/tt] dans une classe et hop elle est visible dans IB comme si on avait mis IBOutlet devant  :o
  • psychoh13psychoh13 Mothership Developer Membre
    décembre 2008 modifié #30
    Bah, chez moi toute variable d'instance typée id et sans underscore est référencée par IB.
    Et d'ailleurs, ce comportement est documenté...
  • AliGatorAliGator Membre, Modérateur
    06:36 modifié #31
    Ah oui c'est pas parce que je l'ai nommée "delegate" mais parce que je l'ai typé "id", en effet bien vu  :o
Connectez-vous ou Inscrivez-vous pour répondre.