JAVA vs Objective-C

  • Créateur du sujet Créateur du sujet Manu
  • Date de début Date de début

Manu

Membre expert
Club iGen
31 Mai 2000
1 744
205
56
Puteaux région parisienne
Je suis tombé sur ce morceau sorti d'une suite de discussion... à apprécier sans modération...

A+

Java Was Strongly Influenced by Objective-C
...and not C++...

A while back, the following posting was made by Patrick Naughton who,
along with James Gosling, was responsible for much of the design of .
Objective-C is an object-oriented mutant of C used NeXTSTEP and MacOS X,
and also available with gcc.

Tom Gall wrote:
> Sean Luke wrote:
>> Blair MacIntyre ([email protected]) wrote:

>>> BZZT. Wrong. Java was modelled on a number of languages, most
>>> importantly Modula-3 and C++.

>> Of course, it's nonsense that Java was modelled off of NewtonScript,
>> but it's even goofier to say that Java was based on Modula-3 and C++.

>> Java's *syntax* may resemble C++, but it has no similarity to C++
>> as a language. Java's chief *semantics* are dynamically-bound and
>> use single inheritance, class objects, and an extensive runtime
system.
>> C++ and Modula-3 are as far away from this model as any
object-oriented
>> language can be.

>> Java is clearly semantically derivative of Smalltalk and other
>> languages related to it. Most notably, NeXT's
>> Objective-C is almost uncannily similar to Java: single inheritance,
>> dynamic binding, dynamic loading, "class" objects, interfaces,
>> and now methods stored as data (a-la Java's "reflection" library),
>> all-virtual functions, you name it. It's almost weird.

> Hardly weird it was by design actually. As I remember my Java history
> Patrick Naughton the gentleman who got the ball rolling was about to
> quit Sun and join up with NeXT. He happened to be on the same
> intermural hockey team as Scott McNealy. Scott told him to hold off,
> write what he thought was wrong with Sun before he left. Patrick
> didn't leave and was one of the original Oak people. I would like
> to think his affinity for NeXTSTEP showed up in Java, with it
> having an close look and feel to that of Objective-C. (The main
> language on NeXTSTEP)

I don't generally read usenet any more (not since the good old days of
comp.graphics in the 80's...), but I happened across this article while I
was messing around with Excite Live... (a pretty cool service in
itself)...

As it turns out, Sean and Tom are both absolutely correct. Usually, this
kind of urban legend stuff turns out to be completely inaccurate, but in
this case, they are right on. When I left Sun to go to NeXT, I thought
Objective-C was the coolest thing since sliced bread, and I hated C++.
So, naturally when I stayed to start the (eventually) Java project, Obj-C
had a big influence. James Gosling, being much older than I was, he had
lots of experience with SmallTalk and Simula68, which we also borrowed
from liberally.

The other influence, was that we had lots of friends working at NeXT at
the time, whose faith in the black cube was flagging. Bruce Martin was
working on the NeXTStep 486 port, Peter King, Mike Demoney, and John
Seamons were working on the mysterious (and never shipped) NRW (NeXT RISC
Workstation, 88110???). They all joined us in late '92 - early '93 after
we had written the first version of Oak. I'm pretty sure that Java's
'interface' is a direct rip-off of Obj-C's 'protocol' which was largely
designed by these ex-NeXT'ers... Many of those strange primitive wrapper
classes, like Integer and Number came from Lee Boynton, one of the early
NeXT Obj-C class library guys who hated 'int' and 'float' types.

Another interesting side-note, (so as not to break any rules on my first
[and last]-ever posting to comp.sys.newton), John Seamons, (who happened
to be Andy Bechtolsheim's roommate at Stanford and largely reponsible for
the first ever port of Unix to the SUN-0) once did a port of Oak (Java)
to the Newton. We were in the midst of trying to do a deal with 3DO to
run as their OS/API, and we didn't have any 3DO dev systems on hand, so
John took apart an Apple Newton 100 and wired it up to a bunch of logic
analyzers, reverse engineered the interfaces and actually got some of the
original Star7 demo to run on this machine. After the 3DO deal tubed, I
think most of the code was lost to history... last I heard, John was out
in Aspen working for wnj, so you never know.

Sigh... we sure knew how to have fun in those days...

-Patrick

-------------
Patrick Naughton
President and CTO
Starwave Corporation http://www.starwave.com/people/naughton
 
Ca tient la route...
smile.gif
 
Pourquoi un titre comme "JAVA vs Objective-C" ? Ces deux langages ne sont pas l'un contre l'autre !
wink.gif

Tout développeur Java sérieux sait bien que Sun n'a pas inventé grand chose avec Java mais juste repris avec pragmatisme les bonnes idées sur la Programmation Orientée Objet présentes dans différents langages.
Malgré tout, on a rien inventé de mieux que Java depuis...
Pour conclure, ayant déjà jeté un oeil à Obj-C ça ne me tente pas vraiment et la syntaxe de Java m'a semblé plus claire... Mais le passage de Java à Obj-C m'a paru en effet relativement simple.

[06 mai 2002 : message édité par eTeks]
 
Le titre je l'ai mis comme cela juste pour attirer l'attention
Pour ce qui est de la syntaxe, je touve au contraire Objective-c plus claire que java.

En effet une methode definie par :

tracerUneLigneDuPoint
frown.gif
NSPoint *)point1 auPoint
frown.gif
NSpoint *)point2

est pour moi plus claire que

tracerUneLigne(Point point1, Point point2)

En outre dans mes programmes objective_c je peux utiliser la syntaxe enfant.nom pour des structures C.

La syntaxe est issue de smallTalk qui est la référence des langages orientés objets. Cette syntaxe est également utilisée dans LISP.

La syntaxe de java a été daite pour mieux attirer les anciens dévrloppeurs C++.

A+
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par Manu:

En effet une methode definie par :

tracerUneLigneDuPoint
frown.gif
NSPoint *)point1 auPoint
frown.gif
NSpoint *)point2

<HR></BLOCKQUOTE>

lol
grin.gif
 
La syntaxe ObjC paraît peut-être hermétique au premier abord, notamment pour les programmeurs C/C++/Java.

Mais lorsque l'habitude est prise (et cela vient très rapidement), elle ne pose plus de problème, et se rapproche réellement du langage naturel, beau tour de force pour ce type de langage!
 
Bon si j'ai quelques heures devant moi j'y jetterai à nouveau un oeil...
Mais habitué à Java et vivant de ce langage, il me semble surtout urgent qu'Apple sorte le JDK 1.4 et Java3D sous MacOS X. Et là aucune nouvelle au WWDC ! Si seulement ça pouvait être inclus dans Jaguar à sa sortie ce serait top (on peut toujours rêver...) !
 
J'ai lu la doc "Object-Oriented Programming and the Objective-C Language" plus quelques autres fournies avec les outils OS X pour développeurs pour me faire une meilleure idée du langage Objective-C.
Tout d'abord, j'ai trouvé très intéressant leur manière de présenter la Programmation Objet : un modèle du genre avec en plus un côté pragmatique qui me plait bien.

Voilà ensuite les différentes choses que j'ai notés :
- ObjC basé sur C ANSI =&gt; autorise tous les mélanges programmation Objet/pas Objet, notion de pointeur toujours trop présente.
- Déclaration et utilisation des messages d'ObjC un peu bizarre alors que c'est une surcouche du C. Ca permet des jolies choses comme [graphique dessineDuPoint :p1 auPoint :p2] mais quand on mélange des fonctions C avec des appels de messages, ça doit être beaucoup moins chouette...
- Pas de constructeur en ObjC avec contraintes sur les paramètres comme en Java/C++. On ne peut pas forcer l'envoi d'un message init. Obligation d'enchaîner les appels avec la super classe dans init.
- Besoin de prédéclarer les types utilisés en ObjC (@class, @protocol).
- id &lt;=&gt; void * =&gt; un peu lache pour le contrôle syntaxique.
- Pas de forwardInvocation en Java, mais c'est un concept plutôt bizarre.
- Garbage Collector minimaliste en ObjC : retain, autorelase, release marche correctement uniquement si la convention proposée est correctement utilisé =&gt; trop dangereux, obligation de faire attention au compteur de référence. D'ailleurs ca rappelle un peu JNI avec NewGlobalRef, DeleteGlobalRef, DeleteLocalRef,...
- Exception pas directement dans ObjC. NS_DURING ... NS_HANDLER ... NS_ENDHANDLER &lt;=&gt; try { } catch () { } en Java mais pas d'équivalent pour throws
- Pas de threads directement dans ObjC (pas de mot clé synchronized) mais utilisation possible des classes Cocoa NSThread, NSLock,...
- Pas de javadoc et de package en ObjC
- Pas de système de sécurité comme en Java
- ObjC et cocoa pas portable

Mon sentiment est qu'un code ObjC et Java peuvent être assez proches si le programmeur respecte bien un ensemble de conventions ObjC.
Mais comme la syntaxe Java est plus contraignante pour le programmeur, ça lui évite beaucoup de bugs de mise au point et le rend plus productif.
En se détachant du C pour créer un modèle pur objet, Java simplifie le C et le C++ et reprend les concepts intéressants d'ObjC (protocol -&gt; interface java) en forçant l'utilisation d'une syntaxe plus stricte et plus typée.

Finalement, je trouve que les p'tits gars de Sun ont très bien bossé en inventant Java. Je regrette vraiment pas de m'y être mis...

[19 mai 2002 : message édité par eTeks]
 
Attention je n'ai jamais comparé les deux langages. J'ai simplement au départ voulu montrer la paternité de Objective-C par rapport à java. C'est d'ailleurs pour cela que java sous OS X est si bien.
En fait ma préférence pour Objective-C est une question personnelle et d'habitude.
En effet j'apprecie beaucoup en Objective-C la séparation de l'interface de son implémentation. c'est l'application stricte du concept majeur de l'orienté objet.
En outre cela permet de créer des prototypes assez rapidemant.
En fait sous OS X le grand attrait d'Objective-C ce sont les frameworks de Cocoa qui pour moi sont sans égal dans l'industrie du développement. Des applis comme Watson sont une illusttration de ce que peut faire un seul programmeur en si peu de temps.
Le fait que AppleScript y soit entièrement basé est une autre illustration.
Dans l'avenir on verra de plus en plus sous OS X d'applis écrites en cocoa objective-c et on sera très surpris par leur qualité et leur puissance.

A+
 
Je vais quand même reprendre tes remarques.
- Obj-C est basé sur C et c'est une bonne chose car pour celui qui connait déjà le langage C au lieu d'apprendre un langage nouveau, il s'uffit de bien appréhender la notion d'objet pour bien l'aborder.
- La séparation de l'interface et de son implémentation est très interressante. C'est là encore pour un programmeur C facilement compréhensible.
- La production de la documentation est facilitée en lisant la partie interface des classes notamment lorsque celle-ci est commentée. D'ailleurs il existe un utilitaire (qui a inspiré javadoc) qui, à partir des interfaces de classses Obj-C produit une documentation ayant la même structure que la doc des classes cocoa d'Apple.
- je peux facilement mélanger les mesages avec des éléments structure du langage C.
- En java il me semble que l'on declare les classes et les interfaces non?
- id n'a rien à voir avec void *. En fait c'est ce qui caracterise le fait que Obj-C soit plus dynamique que Java et surtout moins typé.
- la référence count d'Obj-C a été préféré au garbage collector tout simplement parce que contrairement à java, le runtime d'Obj-C gère la distribution d'objets. Ainsi lorsqu'un objet est envoyé comme paramètre à un autre objet situant dans un autre process sur la machine locale ou une machine distante, cet objet embarque avec lui sa durée de vie sous forme de compteur.
- L'utilisation des threads est beaucoup plus facile à comprendre sous Obj-C. En effet il s'uffit de coder :
[NSThread detachNewThreadSelector:maMethode toTarget:monObjet withObject:moParam]
pour executer dans un thread la methode maMethode de l'objet monObjet qui prend pour paramètre monParam. Simple non?
- Le système de sécurité de java vient de son utilisation dans le développement d'applets. Obj-C n'a pas la même vocation.
- J'ai développé en Obj-C cocoa sous NT et sous Solaris dans Webobject 3.0.
- Dans java tu n'a pas de notion de catégory qui te permet de rajouter à une classe existante une série de méthodes sans la sous classer. (Je l'ai souvent fait pour les classes d'Apple). Cela est très interessant dans le cas d'une réutilisation de classe. En effet toutes les sous classes héritent de ces méthodes A POSTERIORI!!
- Pas de notion de Notification Center dans Java. C'est une notion hyper mal implémentée dans java.
- Pas de notion de déléguation dans java.
Bref tous les ingrédients qui font d'Obj-C +Cocoa l'environnement de rêve pour un programmeur interressé par la programmation orienté objet sur Mac OS X.
Mon plus gros souhait c'est d'encourager tous ceux qui sont interréssés au développement sous OS X à se tourner vers Obj-C et Cocoa. Pour une fois qu'Apple propose quasi gratuitement un environnement de développement non seulement très complet mais qui s'avère être le meilleur qui existe, c'est bête de ne pas en profiter.
Cocoa a beaucoup inspiré les créateurs de java. Mais je n'ai jamais vu sur une quelconque plate forme une application java ne serait-ce de la classe de watson ou même iDVD ou iPhoto ou omniWeb.
alors on peut parler de java ci java ça....
En plus les AWT et autres swing c'est de la m...

En fait le gros avantage de Cocoa Obj-C sous OS X c'est que Apple a COMPLETEMENT INTEGRE LE RUNTIME Obj-C AVEC L'ARCHITECTURE DE L'OS.
un bon exemple est l'implémentation dans le runtime de DO (Distributed objet) que tu peux lire ici : http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/ProgrammingTopics/DistrObjects/index.html

D'ailleurs elle n'est pas valable pour Cocoa-java.

Une classe comme NSTextView qui est à elle seule presque UN TRAITEMENT DE TEXTE n'a pas d'équivalent dans les soit-disant package java.

Je ne parle même pas de WebObjects ou de EOF qui eux ont inspiré les javaBeans, J2EE et consort sans arriver au même résultat.
D'ailleurs Apple a implémenté ces concepts dans WO et c'est un modèle du genre.
Maintenant que les Xserve sont là, ma boîte pourra proposer des solutions webObjects surpuissants à des clients à la place de wesphere et weblogic.

A+

[20 mai 2002 : message édité par Manu]
 
Manu, je ne cherche pas à polémiquer avec toi mais comme tu sembles ne pas connaître Java, je me permets de te répondre pour ton information :
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>
- Obj-C est basé sur C et c'est une bonne chose car pour celui qui connait déjà le langage C au lieu d'apprendre un langage nouveau, il s'uffit de bien appréhender la notion d'objet pour bien l'aborder.<HR></BLOCKQUOTE>

C'était aussi l'argument principal du C++ ! Et justement, ta phrase il s'uffit de bien appréhender la notion d'objet pour bien l'aborder. rélève tout le problème d'ObjC et du C++. Quand peut-on considérer qu'un développeur connait bien la notion d'objet pour le faire participer à un projet ?...
Etudie un peu Java et tu verras que les instructions Java et celles du C sont vraiment proches (si tu veux, tu peux jeter à oeil à mon site Du C/C++ à Java pour t'aider
wink.gif
).

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>
- La séparation de l'interface et de son implémentation est très interressante. C'est là encore pour un programmeur C facilement compréhensible.<HR></BLOCKQUOTE>

De mon point de vue, la séparation de l'interface et de son implémentation n'est qu'une histoire de prédéclaration obligatoire en C et donc en Obj-C (comme en C++ d'ailleurs).
En Java il n'y a pas de prédéclaration, tu déclares les méthodes et tu les implémentes en même temps. Ca peut paraître bizarre quand on vient du C mais ça n'est pas génant du tout et ça simplifie la gestion de fichiers (plus de .h).

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>
- En java il me semble que l'on declare les classes et les interfaces non?<HR></BLOCKQUOTE>

La notion d'interface Java correspond au protocol Obj-C.

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>
- La production de la documentation est facilitée en lisant la partie interface des classes notamment lorsque celle-ci est commentée. D'ailleurs il existe un utilitaire (qui a inspiré javadoc) qui, à partir des interfaces de classses Obj-C produit une documentation ayant la même structure que la doc des classes cocoa d'Apple.<HR></BLOCKQUOTE>

Javadoc est intégré au JDK ce qui le rend bien plus universel et permet même de générer des documents à d'autres formats avec des doclets.

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>
- je peux facilement mélanger les mesages avec des éléments structure du langage C.<HR></BLOCKQUOTE>

Franchement, quelle est la différence entre une structure et une classe dont les champs sont public ? La présence du pointeur _isa en plus ? Ca fait un peu léger comme argument, tu ne trouves pas ?

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>
- id n'a rien à voir avec void *. En fait c'est ce qui caracterise le fait que Obj-C soit plus dynamique que Java et surtout moins typé.<HR></BLOCKQUOTE>

Mais moins typé implique plus d'erreurs à l'écriture des programmes ! Heureusement qu'en échange c'est plus fexible !

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>
- la référence count d'Obj-C a été préféré au garbage collector tout simplement parce que contrairement à java, le runtime d'Obj-C gère la distribution d'objets. Ainsi lorsqu'un objet est envoyé comme paramètre à un autre objet situant dans un autre process sur la machine locale ou une machine distante, cet objet embarque avec lui sa durée de vie sous forme de compteur.<HR></BLOCKQUOTE>

Ca se défend. Mais la plupart des programmes n'utilise pas la distribution d'objets (qui d'ailleurs est géré en Java avec RMI).

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>
- L'utilisation des threads est beaucoup plus facile à comprendre sous Obj-C. En effet il s'uffit de coder :
[NSThread detachNewThreadSelector:maMethode toTarget:monObjet withObject:moParam]
pour executer dans un thread la methode maMethode de l'objet monObjet qui prend pour paramètre monParam. Simple non?
<HR></BLOCKQUOTE>

Et qu'est ce que tu dis de ça ?
Bloc de code:
Moitié moins de caractères à taper en Java !
wink.gif

De toute façon ce qui est compliqué avec les threads, c'est la synchronisation et la gestion des locks, pas le lancement d'un thread tout bête.

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>
- Le système de sécurité de java vient de son utilisation dans le développement d'applets. Obj-C n'a pas la même vocation.<HR></BLOCKQUOTE>

Tu peux t'en servir aussi pour contrôler l'accès à certaines ressources.

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>
- J'ai développé en Obj-C cocoa sous NT et sous Solaris dans Webobject 3.0.<HR></BLOCKQUOTE>

Tout cocoa est disponible sous NT ?

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>
- Dans java tu n'a pas de notion de catégory qui te permet de rajouter à une classe existante une série de méthodes sans la sous classer. (Je l'ai souvent fait pour les classes d'Apple). Cela est très interessant dans le cas d'une réutilisation de classe. En effet toutes les sous classes héritent de ces méthodes A POSTERIORI!!<HR></BLOCKQUOTE>

Là je suis preneur d'informations car je n'ai pas bien saisi la différence entre une sous classe et une catégorie (en Java tu peux empêcher de dériver d'une classe en la déclarant final).

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>
- Pas de notion de Notification Center dans Java. C'est une notion hyper mal implémentée dans java.<HR></BLOCKQUOTE>

Qu'est ce que c'est ?

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>
- Pas de notion de déléguation dans java.
Bref tous les ingrédients qui font d'Obj-C +Cocoa l'environnement de rêve pour un programmeur interressé par la programmation orienté objet sur Mac OS X.
<HR></BLOCKQUOTE>

Ce style de programmation est repris par les listeners (voir specs JavaBeans) et reste relativement simple à programmer avec les classes anonymes. En Obj-C c'est encore plus simple à programmer grâce aux possibilités du faible typage du langage.

Pour le reste je vais lire les docs que tu indiques avant d'en dire plus...

Finalement il me semble qu'il faille faire une nuance et comparer les couples langages Java/Obj-C et bibliothèques Java/Cocoa.
- Côté langage : Java est plus typée qu'Obj-C et pour moi, cette contrainte est un gage de sécurité et de qualité.
- Côté bibliothèque (je n'ai jamais pratiqué Cocoa donc je raconte peut-être des bétises) : Java est sûrement bien plus riche que Cocoa mais peut-être moins homogène.

De quand date Cocoa ?


A+
 
Le combat des Chefs :-)

Continuez messieurs, votre joute est excellente. Ne voyez là aucune attaque ou ironie, vos arguments sont justes et précis, c'est "jouissif"

De java ou Objective-C, je ne sais pas qui sortira vainqueur (s'il doit y avoir un vainqueur) mais j'aimerais féliciter ici Apple pour nous permettre de mélanger tout ce qu'on veut dans nos projets Cocoa: Obj-C, C, C++, Java, tout est bon et c'est assez fantastique. Pour avoir utiliser ces fameux bridge Java (driver MM.MySQL) je peux témoigner que notre palette d'artiste s'est élargie, et continue de s'émanciper.
Apple ne doit toutefois pas s'endormir et rajouter les dernières spécifications Java à cet ensemble !

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par eTeks:
Là je suis preneur d'informations car je n'ai pas bien saisi la différence entre une sous classe et une catégorie (en Java tu peux empêcher de dériver d'une classe en la déclarant final).<HR></BLOCKQUOTE>

Dans une catégorie, tu complètes une classe existante avec tes propres méthodes. Tes méthodes sont littéralement ajoutées à la classe d'origine (tu ne créé pas de sous-classe).
Le principal intérêt, c'est que ces méthodes sont alors accessibles à l'ensemble des sous-classes issues de la classe d'origine. Tu peux ainsi compléter les lacunes de NSString, toutes tes NSString en profiteront.

Pas de notion de Notification Center dans Java. C'est une notion hyper mal implémentée dans java.
[QB]Qu'est ce que c'est ?
[/QB]

Certains objets peuvent s'enregistrer (ou du moins une de leur méthode) auprès d'un Notification Center pour être tenu informé dès qu'un type d'évènement (qu'il choisit) se produit.
Contrairement à la délégation, un objet observateur qui est notifié d'un évènement pour lequel il s'est enregistré demandeur, ne peut interférer sur l'évènement.


Enfin, pour la date de naissance de Cocoa, je dirais 93 soit l'apparition d'OpenStep, fils héritié de NeXTSTEP :-)
 
En fait ce que je veux montrer et surtout faire partager, c'est le gout de cocoa. Franchement je pense qu'aborder l'orienté objet par cocoa est plus facile que le faire par java.
La principale force de cocoa c'est que c'est un environnement de développement comprenant un langage + des Frameworks très riches et dans lequel on trouve depuis l'origine des concepts décrits dans le livre Design Patterns qui soit dit en passant est une lecture obligée pour quiconque est interressé par la programmation orientée objet.
Je vais eclairer un certains nombre de points dans le but surtout de faire avancer le débat et le rendre plus interressant.
- La séparation dans Obj-C de l'interface et son implémentation est plus qu'un simple moyen d'avoir un fichier .c.
C'est je crois un principe essentiel de l'orienté objet.
Dans un projet où l'on défini plusieurs objets métiers, on peut à la limite donner au spécialiste du métier le soin de définir ou de décrire les objets métiers par leur interface. C'est à dire, les attributs et les actions effectuées sur l'objet. Il y ajoute les commentaires pour décrire les actions définies.
L'implémentation étant quant à elle effectuée par un informaticien qui maitrise le langage et les algorithmes necessaires.
D'autre part, l'interface est la partie du code que l'on publie à eux qui veulent réutiliser vos objets sans qu'ils aient besoin de connaitre l'implémentation. A la limite ils peuvent même proposer une nouvelle implémentation.
- Le lancement d'un thread cocoa est plus facile simplement parce qu'en obj-C il existe la notion de pointeur vers une méthode. @selector(). Ainsi on peut décider d'executer n'importe qu'elle méthode dans un thread sans que cette méthode ait cette possibilité à l'origine. Ainsi je peux exécuter une méthode de cocoa dans un thread si mon appli l'exige.
- L'implémentation de la notion de Notification par les listeners est compliquée. Car si j'ai bien compris, l'objet qui veut être notifié doit aller se déclarer explicitement à l'objet qui notifie. alors que dans le cas de cocoa, les deux objets s'ignorent complètement.
-C'est vrai que la notion de synchronisation est un avantage de java.
- Les inventeurs d'obj-C avait privilégié l'efficacité du programmeur à celui du programme. C'est ainsi que la dynamicité du langage reporte à l'exécution la plupart des controles et liens.
D'aiileurs cette attitude est beaucoup utilisé non seulement dans cocoa mais dans Mac OS X tout entier. C'est ce que l'on appelle le 'lazy binding'. Il est utilisé dans la gestion des librairies dynamiques (page 132 de la doc pdf Inside Mac OS X System Overview), et même dans la gestion des drivers. C'est une des particularités séduisantes d'OS X par rapport à d'autres systèmes. On gagne en performance et surtout en flexibilité. C'est en gros l'attitude qui consiste à dire que l'on s'occupe de quelque chose uniquement au moment où l'on en a besoin.
En définitive utiliser cocoa ou java est une affaire de goût et surtout d'expérience.
En ce qui me concerne, j'ai découvert Obj-C avant java. C'est vrai que je n'ai pas beaucoup utilisé java en tout cas pas dans des projets aussi importants que ceux dans lesquels j'ai développé en cocoa.
En résumé pour développer de bonnes applis en cocoa, 3 choses à bien intégrer :
- Le langage Obj-C
- Le concept MVC
- Les outils PB et IB.

A+

[24 mai 2002 : message édité par Manu]
 
Le Java est sympas, Objective-C aussi surtout par addition de Cocoa.
Pour moi je trouve que le grand avantage qu'a l'Objective-C sur le C++ et Java, c'est la recompilation et l'integration des programmes C ( et C++). Aucune modif ne doit etre apportées au code, t'as plus qu'a faire ton wrapper et c'est ainsi que facilement tu fabriques une interface Graphique pour un quelquonque programme.

Juste un avis de passage, mais je soutiens que les Deux langages ont un interet different, l'un une universalité acquise au détriment de la proximité de la machine. Et l'autre une belle aproche de la notion d'objet tout en restant suffisament proche de la machine, permettant une optimisation consequente.
 
Moi je dis : n'hésitez pas à continuer. Tout ça est très intéressant même si je capte pas tout tout. J'avais lu une doc sur stepwise ou autre chose sur les concepts orientés objets et leur mise en pratique dans Objective-C ; c'était très intéressant. C'est dans ce type de lecture qu'on se rend compte que malgré tout Cocoa c'est vraiment, comme le dit Manu, des Frameworks mais surtout un langage qui à la base, tout nu, permet d'utiliser les concepts objets mais aussi des mécanismes bien plus complexes ( j'ai pas dit compliqué ) à la smalltalk. Mais là Manu sera sûrement plus apte à nous l'expliquer.
Je pense qu'Apple et c'est sûrement voulu ne fait pas la distinction entre ce que permet Objective-C sans les frameworks et vice-versa. D'après ce que j'ai compris des tas de concepts Cocoa ne sont que des aptitudes d'Objective-C.
 
Pour approfondir la discussion, j'ajouterai ceci :
Le langage objective-C est un descendant direct de smallTalk Il a été choisi à l'époque par NeXT car il était accessible par quiconque connait le langage C. Ce qui est vrai pour la plupart des gens qui font de l'Unix.
Les qualités de ce langage sont les mêmes que celles de smallTalk à savoir qu'il est dynamique c'est à dire que la plupart des vérifications sont reportées à l'exécution.
Mac OS X et surtout NeXSTEP avant lui est un systeme basé sur le micro noyau Mach.
Or justement les inventeurs de Mach étaient influencé par les concepts objet. C'est pourquoi on retrouve dans l'architecture de Mach des concepts utilisés en orienté objet.
Par exemple sous Mach un thread (qui est l'élément executable dans Mcah) et non un process comme dans les systèmes unix, est un objet référencié par un port. Pour demander à un thread d'exécuter une action, on lui envoie un message sur son port. Cette notion de port, on le retrouve aujourd'hui répandu dans tous les systèmes. C'est ainsi par exemple que le process httpd reçoit les requêtes http sur le port 80.
Cette conception objet se retrouve également dans la gestion de la mémoire virtuelle sous Mach où l'on parle d'objet mémoire.
Cocoa est un ensemble de Frameworks (classes de base définies par Apple).
Outre le fait de fournir des classes pour faciliter le développement d'applications, Apple a également iinclus dans les frameworks des classes qui implémentent des fonctionnalités offertes par le système Mach.
C'est ainsi que l'on retrouve dans cocoa des classes d'objet qui 'wrape' des objets ou des fonctionnalités de Mach. NSThread, NSPort, NSTask, NSNotificationCenter, NSConnection ..etc.
C'est d'autant plus vrai que dans la version Windows appelée à l'époque Yellow Box, Apple fournissait un serveur qui simulait Mach. (MachServer).
C'est pour cela que cocoa et Mac OS X sont intimement liés.
Sans compter le fait que mêmes les technologies graphiques d'OS X sont gérées nativement dans cocoa.
Exemple tout texte cocoa est unicode.
Les éléments d'interface sous cocoa héritent dàs l'origine des techniques avancées de Quartz.
OmniWeb en est une illustration.
L'autre effort fournit par Apple concerne la qualité des classes de cocoa qui est telle que le développeur trouve son boulot mâcher à 75% des cas. Exemple, une classe NSMovie implémente à elle seule presque une bonne partie des fonctions video.
Comme je l'ai toujours dit avec cocoa on programme à un niveau plus élevé car l'essentiel est fourni par les frameworks.

A+