[Résolu] Bug ARC ?

christopheL

J'ai un objet sur lequel je veux implementer le protocole NSCopying.



j'ai donc implémenté la méthode :

<br />
- (id)copyWithZone:(NSZone *)zone {<br />
	id copy = [super copyWithZone:zone];<br />
  <br />
	if (copy) {<br />
		// Copy NSObject subclasses<br />
		[copy setPropriete:[self.propriete copyWithZone:zone]];<br />
	}<br />
  <br />
	return copy;<br />
}<br />

or Xcode me sort une erreur à  la compilation :



ARC Semantic Issue :

"multiple methods named setPropriete founds with mismatched results, parameter type or attribute."

avec en dessous : "One possibility" et "Also found"



alors effectivement, j'ai 2 classes avec une propriété du même nom "propriete" ces deux classes ayant la même classe mère. Ces deux propriétés "propriete", l'une étant un NSDictionary, l'autre un int. L'autre objet n'implémentant pas <NSCopying>.



Comme je lui indique "self.propriete" il ne devrait pas se planter. Bien sur, je pourrai changer le nom de l'une des deux.



Selon vous, est-ce un bug d'ARC ? Puis-je le "forcer" en lui indiquant à  laquelle des deux il doit se référer (même si l'utilisation de "self" aurait dû le mettre sur la voie) ? Sachant que c'est une erreur de compilation et non un warning.



Question subsidiaire, ai-je loupé un truc avec ARC (ex: ne jamais avoir des propriétés avec le même nom pour des objets différents ou partageant la même classe mère) ?

christopheL

Bon, j'ai trouvé, c'est ma faute /biggrin.png' class='bbc_emoticon' alt=':D' />



au lieu de :

<br />
id copy = [super copyWithZone:zone];<br />

j'aurai dû mettre :

<br />
maClasse *copy = [super copyWithZone:zone];<br />

AliGator

Oui le type "id" permet le typage dynamique, ce qui peut s'avérer bien pratique, par contre si tu appelles une méthode X sur un objet déclaré en tant que "id", du coup dans certains cas comme celui-ci il ne peut pas savoir (du moins à  la compilation) quelle méthode X appeler, car il ne sait pas à  la compilation quelle sera la classe de ton objet déclaré en "id".



Alors bien sûr, si ta méthode X est déclarée pour plusieurs classes mais toujours avec la même signature, pas de problème, au Runtime il va savoir de quel type est ton objet déclaré en "id" et donc va savoir la méthode de quelle classe appeller, en fonction de la classe de ton objet.

Mais si tu as plusieurs méthodes avec le même nom X mais avec des signatures différentes (en particulier des types de paramètres différents), à  la compilation il ne va pas savoir quelle signature du coup aura ta méthode X (puisque selon si ton objet est de type A ou B la méthode X associée aura des paramètres de type différents donc une signature différente) et donc je va pas savoir créer à  la compilation un symbole et selector cohérent ni vérifier que tu passes bien les paramètres de type attendu, d'où le warning.



Ainsi si tu as plusieurs classes (même si elles n'ont rien à  voir entre elles) qui déclarent toutes une méthode "-(void)toto:(NSString*)str", pas de soucis, mais si tu as des classes qui déclarent "-(void)toto:(NSString*)str" et d'autres qui déclarent "-(int)toto:(NSArray*)arr" là  il va s'embrouiller et te mettre ce warning. Et c'est sans doute le cas de ta méthode setPropriete, bien sûr.



En passant d'ailleurs, c'est une très mauvaise pratique d'avoir plusieurs méthodes de même nom dans diverses classes mais avec des types de paramètres différents. Pour la raison du cas où tu as ce warning, mais aussi pour des raisons de cohérence. Tu devrais essayer de mieux coller aux conventions de nommage et, du coup, si tu as plusieurs méthodes au même nom éparpillées dans diverses clases mais qui prennent chacune des paramètres de type différent, tu devrais mieux nommer ta méthode pour indiquer le type de paramètre attendu pour éviter les risques de confusion (genre "setIntProperty" et "setStringProperty" ou je ne sais quoi

christopheL

'AliGator' a écrit:

En passant d'ailleurs, c'est une très mauvaise pratique d'avoir plusieurs méthodes de même nom dans diverses classes mais avec des types de paramètres différents.

Oui, ce n'était pas spécialement voulu, ca restait dans la logique de chacune des classes et je ne m'en étais même pas rendu compte.



Du coup j'ai cherché dans les options de compilations s'il existait un warning à  activer pour un doublon de méthodes pour des classes différentes avec paramètres / type de valeur retournée différents, je n'ai pas trouvé.