Discussion à  propos de l'Objective-C 2

2»

Réponses

  • muqaddarmuqaddar Administrateur
    13:59 modifié #32
    Merci les gars !

    Je crois que je vais faire comme Ali, pour la logique d'accès aux propriétés de l'objet.

    [EDIT] Et puis ça me rappelle un peu mon ruby sur le coup...
  • psychoh13psychoh13 Mothership Developer Membre
    13:59 modifié #33
    La syntaxe pointée et le @property n'ont aucun rapport entre eux. La preuve c'est qu'on peut utiliser le point avec n'importe quelle méthode KVC-compliant, c'est-à -dire : - (Type)<methodName> ou - (void)set<MethodName>:(Type)value;

    Avec cette règle, il y a beaucoup de méthode que l'on peut utiliser avec le point, je cite en vrac : init, retain, release, retainCount, autorelease, copy, mutableCopy, zone, self, class, superclass, hash description, finalize, dealloc, etc. Et ça c'est juste des méthodes de NSObject.

    Les deux syntaxes ont été ajoutées en même temps comme étant liée, mais elles n'ont rien à  voir et sont totalement indépendantes. La syntaxe pointée c'est du sucre syntaxique, alors que @property est un outil extrêmement utile.

    Pour commencer, @property te permet de ne pas avoir à  déclarer les méthodes manuellement, ça réduit le code et en plus tu peux mettre plusieurs propriétés pour un @property (les propriétés partagent type et attributs), ensuite, tu as le choix entre :
    • Demander au compilateur de générer automatiquement les implémentations avec @synthesize, tu as grâce à  ça, une implémentation propre et efficace qui fait ce que tu lui demandes et en plus tu n'es pas gênée par les lignes répétitives.
    • à‰crire les méthodes toi-même, ou fournir l'une des deux implémentations, le @synthesize se chargera de générer la méthode manquante.
    • Ou bien de dire au compilateur "l'implémentation de cette méthode sera fournie à  l'exécution" avec @dynamic.


    Ce dernier point est très intéressant, car il permet d'indiquer au compilateur quelles sont les messages auquel l'objet sera capable de répondre à  l'exécution sans pour autant avoir besoin d'écrire la méthode. Ensuite, il suffit de s'assurer qu'à  l'exécution ces méthodes seront fournies ; ça peut être soit par simple -resolveMethodWithSelector: ou encore par -forwardInvocation:, ou bien dans le cas des plugins Quartz Composer, la méthode peut être fournie par quelqu'un d'autre. QC utilise ça pour les méthodes qui vont servir d'input et output dans les patchs.
  • schlumschlum Membre
    13:59 modifié #34
    dans 1239531855:

    La syntaxe pointée c'est du sucre syntaxique, alors que @property est un outil extrêmement utile.


    Mais tout autant du sucre syntaxique... À priori, ça génère seulement le code avec une syntaxe plus courte non ?  :P

    La syntaxe pointée, AMHA c'est c'est pour faire les yeux doux aux développeurs Java, tout comme le garbage collector...
  • psychoh13psychoh13 Mothership Developer Membre
    13:59 modifié #35
    C'est clairement du sucre syntaxique. Si tu compiles en ASM sur GCC, tu as seulement 3 petites différences au niveau des registres, alors peut-être qu'à  ce niveau il y a une optimisation.

    Cependant, quand on compile avec Clang, et qu'on fait -emit-llvm c'est-à -dire dans le langage utilisé par LLVM pour faire un exécutable, et là  il n'y absolument aucune différence entre les deux codes émis.
    Donc soit Clang ne sait pas encore optimiser les propriétés, soit il n'y a rien à  optimiser et les deux codes font exactement la même chose.
Connectez-vous ou Inscrivez-vous pour répondre.