Bon, ok. Au final, laissons les accesseurs à @synthetize...
Une dernière (enfin pas sûr) chose : Est-il gênant de déclarer atomic les propriétés si l'application n'est pas multithread ? (mais pourrait le devenir par la suite...) perte de performances ?
Si l'application n'est pas multithread, laisser les propriétés en "atomic" (c'est à dire ne PAS mettre "nonatomic") va avoir pour conséquence que les setter/getter seront encapsulés autour d'un @synchronze(self) qui est purement inutile en monothread. Donc dans l'absolu, oui, laisser en "atomic" les propriétés si tu n'es pas multithread peut générer une perte de performance. Après elle reste négligeable je pense (vu qu'en monothread, le lock implicite généré par @synchronized sera toujours libre, aucun autre thread n'ayant pu le demander. Donc bon ça risque d'être aussi pénalisant qu'une seule instruction de plus dans ton code, j'imagine.
Réponses
retain/autorelease est "nécessaire" mais loin d'être suffisant en multithread.
il est vrai que @property/@synthesize masquent un peu les problemes.
Une dernière (enfin pas sûr) chose : Est-il gênant de déclarer atomic les propriétés si l'application n'est pas multithread ? (mais pourrait le devenir par la suite...) perte de performances ?
pour l'instant l'optimisation, ce n'est pas (encore) un problème.
règle N°1: (que malheureusement je ne suis pas tjrs) en développement ne PAS OPTIMISER
règle N°2: (que malheureusement je ne suis pas tjrs) optimiser seulement a l'aide d'un profileur
.../...