syntaxe de l'objective C

beltbelt Membre
juin 2004 modifié dans API AppKit #1
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.

Réponses

  • mpergandmpergand Membre
    13:50 modifié #2
    Si tu veux une syntaxe proche du C, tu peux utiliser Java !
  • 13:50 modifié #3
    Bah moi au contraire j'adore cette syntaxe que je trouve plus lisible que celle à la Java qui devient trés fouillie dès qu'on commence à enchainer les appels de méthodes prenant des paramètres.

    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.
  • ibeniben Membre
    13:50 modifié #4
    La syntaxe de l'objective-C avec les crochets a des avantages.

    - 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é.
  • 13:50 modifié #5
    Je confirme: l'Appkit via java est nettement moins poussé que celui en Obj-C (par exemple pas d'accès au webkit, aux objets distribués, au panneaux de préférence, au carnet d'adresse,...). En plus les applications créées de cette manière sont beaucoup plus lentes.

    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);
  • mpergandmpergand Membre
    13:50 modifié #6
    dans 1088238362:

    Je confirme: l'Appkit via java est nettement moins poussé que celui en Obj-C (par exemple pas d'accès au webkit, aux objets distribués, au panneaux de préférence, au carnet d'adresse,...).

    Malheureusement vrai, mais il existe des solutions comme Webkit


    En plus les applications créées de cette manière sont beaucoup plus lentes.


    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.
Connectez-vous ou Inscrivez-vous pour répondre.