Le 12 févr. 08 à 13:31 (soir), Benoit Widemann a écrit:
Ce n'est pas tout à fait ça. Cocoa s'appuie largement sur les mêmes
fondations que Carbon. La différence majeure reste dans les
"couches hautes" et même là, il est tout à fait possible d'appeler
Carbon depuis une appli Cocoa ou vice-versa. Les NSString de Cocoa
sont directement utilisables comme CFString de Carbon, de même
qu'un CFDictionary peut être passé en argument à Cocoa comme si
c'était un NSDictionary. NS = "next step" (on devine l'origine de
Cocoa...), CF = core foundation.
Ce qui est tout de même exact, c'est que la *forme* d'appli qu'on
appelle couramment "appli Carbon", c'est-à-dire utilisant encore
l'architecture CFM comme sous Mac OS 9 et CarbonLib, tend à la
disparition et est officiellement considérée comme obsolète par
Apple. Le passage sous "Mach-O" est préconisé depuis longtemps,
mais une appli architecturée Mach-O peut tout à fait être
essentiellement écrite en Carbon, auquel cas elle n'aura rien
d'obsolète.
http://en.wikipedia.org/wiki/Mach-O
RB a un autre aspect à prendre en considération qui est son
caractère interprété. Je connais mal l'architecture runtime de RB,
mais je suppose qu'il y a une part interprétée avec un runtime pour
chaque plate-forme de déploiement ? Ça laisse les options ouvertes,
car si le runtime Mac OS X est aujourd'hui en CFM, rien
n'interdirait d'en faire un en Mach-O.
Merci bien pour ces explications!
Il y a une différence notable à laquelle je pense: une fenêtre en
Cocoa peut être déplacée alors même que l'application est bloquée, ce
qui n'est pas le cas en Carbon (donc pas en RB actuellement). Donc il
y a quelques différences au delà des types de données (CF ou NS).
D'ailleurs, votre explication est intéressante pour moi: je croyais
que NS... et CF... n'étaient pas différenciées en Carbon ou Cocoa.
C'est vrai que "NS" (next step) fait curieusement penser à l'origine
de Mac OS X!
|