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

Gercofis · décembre 2008

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 ?

AliGator · décembre 2008

Heu oui on (heu... même... toi, d'ailleurs

) avant déjà posté à ce sujet ici non ? ;D

schlum · décembre 2008

C'est quoi le problème avec la page 60 ? ça parle juste des règles avec les constructeurs "init" ???

Gercofis · décembre 2008

Juste la partie en dessous.

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

schlum · décembre 2008

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.

Chacha · décembre 2008

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

Gercofis · décembre 2008

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

schlum · décembre 2008

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 !

Chacha · décembre 2008

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

psychoh13 · décembre 2008

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.

Gercofis · décembre 2008

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é...

schlum · décembre 2008

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).

schlum · décembre 2008

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

schlum · décembre 2008

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).

Gercofis · décembre 2008

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

Chacha · décembre 2008

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

schlum · décembre 2008

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é.

Gercofis · décembre 2008

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 ?

schlum · décembre 2008

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.

Gercofis · décembre 2008

Pour info la relecture technique est réalisé pas Fabien Schwob
et son site est la :http://www.cocoa.fr/
En cas de questions...

Antilog · décembre 2008

Tiens!!

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

Rubrique compléments

:fouf):

Gercofis · décembre 2008

Même que si tu vas en bas et que tu lis l'avis d'un lecteur d'Amazon ça pourrais bien être moi...

Gercofis · décembre 2008

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...

psychoh13 · décembre 2008

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.

AliGator · décembre 2008

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)

psychoh13 · décembre 2008

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...

schlum · décembre 2008

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"

psychoh13 · décembre 2008

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.

AliGator · décembre 2008

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

psychoh13 · décembre 2008

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é...

AliGator · décembre 2008

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

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

Réponses