syntaxe de l'objective C
belt
Membre
Je découvre cocoa et l'objective C et cela paraà“t très prometteur. Un regret cependant, je trouve que la syntaxe de l'objective C (C à la sauce smalltalk) est un peu curieuse. Personnellement, au lieu de :
[myobject methode : parm1] ;
je préfererai écrire :
myobject.methode(parm1) ;†plus lisible et plus proche du C
Je ferai une remarque semblable pour la déclaration et l'implémentation des méthodes.
Voilà maintenant ma question : est-il possible (par des macros ou par d'autres moyens) de "C-ifier" l'objective C ?
Y'a-t-il quelqu'un qui l'a fait ?
Merci pour vous réponses.
[myobject methode : parm1] ;
je préfererai écrire :
myobject.methode(parm1) ;†plus lisible et plus proche du C
Je ferai une remarque semblable pour la déclaration et l'implémentation des méthodes.
Voilà maintenant ma question : est-il possible (par des macros ou par d'autres moyens) de "C-ifier" l'objective C ?
Y'a-t-il quelqu'un qui l'a fait ?
Merci pour vous réponses.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Si vraiment tu ne supportes pas les crochets tu peux utiliser le binding Java du framework Cocoa pour programmer (mais tu auras accès à moins de fonctionnalités il me semble). ¿ part ça non je ne vois pas de moyens de faire ce que tu dit.
- Le code objective-C est facilement repérable au milieu de code C:
†Imaginons les parenthèses et que ta classe A possède une méthode sleep(int).
†Comment différencie-tu le sleep normal unistd.h, et celui de ta classe si tu les appels tous les deux avec sleep(1) par exemple.
†Un cas encore plus fort serait celui où ta classe hériterait de A écrit par quelqu'un d'autre et donc que le sleep ne te serait pas forcement connu / présent à l'esprit
†quand tu écrit l'appel.
†ça évite d'appeler une méthode en croyant en appeler une autre. http://c2.com/cgi/wiki?LawOfDemeter
- Le code objective-C est 100% compatible avec le code C
†Aucune transformation / extension de mots clefs du C. (contrairement au C++)
- Tu peux en tirer des conclusions
†Les méthodes [] sont toutes des méthodes dynamiques (résolue à l'exécution),†contrairement à celles (),
†Elle sont plus lentes, à cause de l'indirection,
-†De plus, la norme (l'habitude) Objective-C / Cocoa recommande les noms à rallonge qui sont là pour être très compréhensible
††et surtout pour éviter des conflits entre les classes qui aurait des méthodes de mêmes noms trop facilement sinon.
††Cela permet d'avoir des @selector identiques uniquement quand les méthodes le sont vraiment,
††c'est à dire ont les mêmes noms et les mêmes noms de paramètres.
††Donc il faut un syntaxe qui aide cette écriture.
††on apprécie alors la syntaxe [nomTresLongARallongeQuiNeFinitJamais:argument0
†††††††††††††††††††††††††††††††††††††††††argument1:argument1
†††††††††††††††††††††††††††††††††††††††††argument2:argument2]
Pour résumer je dirais que c'est le prix à payer pour bénéficier du C sans devoir le modifier, et du typage et de l'appel dynamique en toute sécurité.
Pour la syntaxe, tu verras, tu t'y habitueras. Et quand tu as des méthodes du genre (c'est un exemple un peu extrême):
[NSEvent keyEventWithType:type location:location modifierFlags:flags timestamp:time windowNumber:windowNum context:context characters:characters charactersIgnoringModifiers:unmodCharacters isARepeat:repeatKey keyCode:code];
C'est nettement plus facile pour comprendre où placer les arguments que là, où il est nécessaire de regarder ce qui doit aller où:
event.keyEvent(type, location, flags, time, windowNum, context, characters, unmodCharacters, repeatKey, code);
Malheureusement vrai, mais il existe des solutions comme Webkit
Ce n'est plus vrai avec panther (ce qui prouve que le problème vient d'OS X et non de Java)
Préférer tel language plutôt que tel autre est bien s?r subjectif, mais pour moi Java possède quelques avantages:
- pas de headers
- gestion automatique de la mémoire ( garbage collector )
- pas de pointers
- vaste biblio de classes
En bref, Java est plus simple et sans prise de tête.