Ben oui, c'est clair qu'il reste des efforts à faire côté portabilité, c'est évident. Mon commentaire était absolument pas sur le terrain "nous on est mieux" -- je suis persuadé que FOX (qui autant que je m'en rappelle est un toolkit C++ assez sympa) propose une meilleur solution pour le dev linux/windows que gnustep ... pour le moment du moins :)
C'était juste que j'ai, au premier degré, trouvé le commentaire dans la Faq assez amusant : expliquer que Objective-C, un langage dynamique et moins fortement typé que C++, aurait été plus adéquat pour justement avoir un meilleur contrôle du typage...
Quand à la communauté C/C++ ... elle a TOUJOURS été plus importante que celle ObjC. Rien de nouveau sous le soleil hein.
Reste que la qualité d'un langage/toolkit/bidule n'est pas dépendant du nombre. On trouve d'excellents trucs pas très répandus (style, Erlang), et des trucs moisis largement répandus (style, tout le monde à un exemple bien connu en tête). Et on trouve d'excellents trucs répandus (heu... quoique c'est bizarrement assez rare en fait) et des trucs moisis pas répandus du tout.
Selon moi, GNUstep est un excellent toolkit -- même il reste pas mal de boulot à faire. Cependant, le potentiel est là. Et Objective-C est un excellent langage, vraiment agréable (ne serait-ce que les catégories !!).
Perso, j'ai jamais pu me faire à l'interface de Dia. Vraiment, elle est plus que moyenne. Ce qui est dommage, car il y a des fonctionnalitées sympas (ou qui ne demandent qu'à l'être :) -- avec boites de dialogues pour l'uml, etc.
Par contre, une UI qui roxorise grave pour faire des diagrammes, c'est ... xfig.
Oui, ce vieux truc tout pas beau (encore qu'il soit possible de le passer en xaw3D, heureusement). Et ben pour faire des diagrammes, c'est nickel -- très rapide à créer, ultra-simple de se créer de nouveaux objets à coller en bibliothèque (très très dur la bibliothèqe -- il suffit de copier les fichiers xfig dans un répertoire; pour faire des sous-entrées, créez des sous-répertoires ... trop dur vraiment !)
Il gère les images, les liens automatiques (vous bougez une figure, les flêches suivent), permet de changer le texte d'une figure sans avoir à "l'ouvrir" (dans le cas d'une figure composée), permet d'exporter dans une tripotée de formats vectoriels différents (dont eps et pdf évidememnt), et accessoirement permet d'écrire du LaTeX dans les champs texte (pratique pour ajouter des formules). Il gère évidemment les calques, et dispose d'une bibliothèque d'objets pas trop mal (même si on pourrait avoir mieux).
Enfin, et surtout, l'UI est vraiment bien foutue, avec les raccourcis-clavier à une touche. Une main sur le clavier, l'autre sur la souris, et hop !
Pour faire du dessin vectoriel, Inkscape/Sodipodi/Sketch sont très bien (Inkscape est vraiment pas mal) ... pour des diagrammes, par contre, je reste à xfig.
La seule chose, c'est que tu as le CHOIX de typer ou de ne pas typer tes objets.
Tu peux fonctionner simplement en utilisant le type objet de base "id" mais tu peux aussi déclarer tes objets comme étant d'un type d'objet donné (NSString pour les chaînes de caractères par exemple). Accessoirement, tu as tout ce qu'il faut pour vérifier les implémentations des interfaces (protocoles) aussi.
Quel rapport ? WindowMaker n'utilise pas le framework GNUstep et n'est même pas codé en Objective-C. Il se trouve juste que le look'n feel est similaire à celui du NeXT.
Les auteurs ont l'air d'être les héritiers de Don Knuth (auteur de TeX) si on regarde leur amour de la typographie (musicale dans ce cas) :-)
LilyPond est, comme (La)TeX, un moteur de mise en page, qui d'ailleurs utilise LaTeX pour gêrer ses pages et le texte, et METAFONT (le programme de TeX pour créer des fontes vectorielles). Et comme pour LaTeX, des éditeurs graphiques externes existent ...
Les auteurs de LilyPond sont en fait d'avis que de toute façon une interface graphique n'est pas idéal pour ce qu'ils font (et même si je trouve ça difficile à imaginer, vu que je *sais* que c'est effectivement vrai pour le traitement de texte (en bon afficionado de LaTeX que je suis), je leur laisse volontier le bénéfice du doute :-)
Bon, la critique est facile ... mais moi ce qui m'intéresserait de savoir, c'est ce que toi tu aurais voulu y trouver, dans ce mag !
Enfin, ça semble un peu comme d'hab -- y'en a qui trouvent le mag trop pointu, d'autres pas assez, d'autres trop orienté programmeur, d'autres couvrant des sujets déjà connus ... On peut quand même imaginer que c'est loin d'être simple de faire un mag qui convienne à tout le monde -- et il y aura toujours des gens que ça n'intéresse pas.
tu risques finalement d'élire non plus le candidat qui aura obtenu le plus de voix +, mais celui qui aura obtenu le moins de voix -. Bref, bonjour la démocratie.
Parceque, FRANCHEMENT, ça change beaucoup de ce qu'on a en ce moment ? on ne comptes plus le nombre de gens qui votent pour "le moins pire" ...
Au moins ça aurait le mérite de séparer les votes "pour" et les votes "contres". Intéressant pour savoir un peu mieux ou on mets les pieds je trouve.
Dans ce cas, ils pourraient remplacer le C++ par l'ObjC simplement ? non ? c'est idiot ?
Non, au contraire. C++ est parfait pour certaines choses, mais à mon sens, pour programmer des GUI, ObjC est plus adapté (messages, dynamisme..). Bon après, personnellement je trouve que le framework OpenStep est justement au top pour ça, car élégant et exploitant bien ObjC. Mais bon, quitte à réinventer la roue pour un toolkit graphique, oui, ObjC me semble une meilleure idée que C++.
Ah, quand je parlais d'améliorer l'AppKit, je voulait dire d'améliorer l'implémentation actuelle de GNUstep hein... l'AppKit en lui même (design) ne nécessite pas vraiment de bouleversement -- Apple ne l'a d'ailleurs pas vraiment touché ... juste ajouté quelques nouveaux widgets (si, ils ont ajouté NSDocument également, mais bon..).
Pour ma part la solution serait l'Objective-C avec la conservation du Foundation Framework de GNUstep et la création d'un GUI spécifique Gnome.
Heu... franchement, l'intérêt serait très limité. Pourquoi créer une GUI spécifique Gnome alors que l'ApplicationKit existe ? il est laaaargement plus intéressant de continuer à bosser sur l'AppKit pour l'améliorer que d'implémenter un framework graphique inspiré de gnome, hein. L'AppKit est un foutu bon framework -- voire même, c'est ce qu'il y a de plus intéressant dans OpenStep -- FoundationKit est sympa, mais le truc qui tue, c'est l'AppKit hein.
Il faut également que l'ObjC permet la communication inter-process, la distribution d'objets de manière quasi-transparente (plus facile que le Net-remoting de .NET).
Ouah! y'a pas que moi qui m'en souviens, cool :-D
Francement, c'est mon hacker prefere -- ce qu'il avait fait avec Spectre, ca, c'etait quand meme un sacre tour de force. Et puis tout simplement, ses articles etaient fabuleux, completement dans l'ethique hacker. Il a d'ailleurs ecrit un article assez connu sur Tesla, le plus grand des hackers selon lui :)
MDI ne peut s'empecher de faire parler de lui en permanence.
D'un autre cote, est-ce qu'on doit reellement lui reprocher ? en etant objectif, avoir un responsable de projet "communicatif", ca aide sacrement le projet en question... et on ne peut nier qu'une bonne partie de l'interet que gnome a suscite a ete du a MDI. Il existe pas mal de projets libres qui ont au contraire du mal a avancer a cause d'un manque de reconnaissance/marketing, mais qui techniquement sont meilleurs que d'autres plus connus. La technique ne fait pas tout -- avec le LL on ne change pas de planete, le facteur humain reste important :)
Merci. Effectivement, ca a l'air interessant, on peut imaginer des applications sympas. Ca ne me parait pas non plus etre une fonctionnalitee a ce point vitale, mais bon, c'est a voir.
Je comprends pas bien: Application, tu dois sous entendre plusieurs process (sinon corba n'a pas de sens), et donc me dire que c'est rare d'avoir des process programmé à l'aide de langage différent, je suis pas trop... Ton explication semble être: tout faire en corba c'est pas top. D'accord, tout d'abord c'est impossible (ce n'est qu'un orb!), ensuite et surtout ce n'est pas le cas.
Ce que je veut dire, c'est que pour un 'bureau' ou l'on veut avoir des composants graphiques externalises, on a pas forcement besoin de tout ce que propose Corba. Le point qui est eventuellement litigieux est la possibilite d'etre independant du langage -- mais ce que je remarque, c'est que tres souvent, le langage utilise est le meme pour l'ensemble des applis/composants.
La tres tres grande majorite des applis KDE sont en C++, la tres tres grande majorite des applis GNOME en C, et cote GNUstep, je connais pas d'appli (graphique, cote serveur il y en a...) qui utilisent par exemple les bindings Java. Mixer differents langages est l'exception plus que la norme.
A mon avis ca s'explique par le fait que les bibliotheques sont d'abord faites pour un langage donne et tirent partie des avantages du langage, et que finalement, il est souvent prefererable d'utiliser le langage "reconnu" si l'on veut tirer partie de toutes les capacitees proposees. Ca peut aussi etre simplement un lag entre les versions des librairies accessibles par les bindings et les versions courante.. mais le resultat est le meme.
Enfin, pour les rares cas ou l'on veut effectivement utiliser un autre langage, encapsuler ton code (utilisant un autre langage que le "principal") dans un composant 'leger' code lui en utilisant le langage dans lequel les libs sont codes n'est pas bien complique.
Accessoirement, le coup d'utiliser du C parce que ca facilite les bindings est plus ou moins vrai... certes, ca peut faciliter, mais bon, KDE propose par exemple des bindings pour une foultitude de langages, et meme GNUstep, avec peu developpeurs, propose des bindings en Java, Ruby, Scheme..
Bref, emmerder tout le monde (utiliser un langage procedural pour faire de la POO) et reinventer la roue (C "objet") pour cette raison (facilite des bindings) est plutot une decision pas si justifiee, au final, non ?
Dans l'absolu, oui. En étant réaliste: c'est inévitable, l'histoire de compromis à nouveau...
Oui, mais c'est ce "compromis" que je trouve vaseux, justement. Mais bon, c'est juste mon opinion, je trouve contre-productif de faire du developpement objet en C, c'est tout.
ps: tu connaissais Miguel De Icaza avant Gnome? moi pas.
En fait j'ai l'impression que ton argument est plus: pq les langage n'offre pas plus de facilité? on est d'accord.
Pas exactement; mon argument était plutôt, certes Corba apporte des trucs sympas, mais en pratique, a-t-on réellement besoin de tout ça ? dans la plupart des cas, non. Utiliser Corba est donc trop lourd pour un intérêt assez limité. Dans ce cas, je trouve qu'utiliser un modèle plus léger est plus efficace et sensé.
Là ou je suis moins d'accord c'est sur le fait de pouvoir utiliser un composant depuis n'importe quel langage: en local c'est déjà assez courant (regarde le nombre de binding c++, python, perl, php, whatever qu'il existe pour des lib c... alors qu'avec un format "standard" on pourrait s'en passer). Mais une fois en remoting, c'est capital il me semble: tu ne peux pas contraindre tout tes projets à être en objective-C! Ce langage est sous doute adapté à certaines choses, mais le sera moins à d'autre, particulièrement en tenant compte de l'existant.
Non, je maintiens ce que je dis : dans un programme donné, il est rare d'avoir plusieurs langages. Les bindings existent, certes, mais sont-ils largement employés? pas tant que ça. Enfin, je ne dit pas du tout qu'utiliser DO est la panacée qui répondra à tous les besoins, simplement que DO est idéal pour utiliser des objets répartis dans ton application, si tu programmes en Objective-C.
Et accessoirement, faire un pont DO <-> Corba ne serait pas si compliqué, vraiment. Personne ne l'a implémenté dans le libre, parce que l'intérêt est honnêtement limité ... mais c'est ce que NeXT avait fait (début des années 90).
Pour synthétiser, intellectuellement, un modèle de composant qui fonctionne avec n'importe quoi, à la Corba, peut être intéressant. Mais en pratique, tu vas utiliser ça dans 1% des cas... il est logique alors de privilégier une solution plus simple -- mais plus efficace. C'est que font GNUstep et KDE. De toute façon, rien n'empêche de réaliser des ponts vers corba si vraiment tu y tient !
Pour le reste, c'est soit des répétions, soit de la mauvaise fois (tu ne connais ni C# ni .NET mais c'est pas une bonne idée...)
Evidemment que je suis un peu de mauvaise foi :-)
mais bon, je n'ai pas dit non plus que je ne connais absolument pas C# ou .Net -- juste que ce que j'en sais ne m'a pas intéressé et donc que je ne m'y suis pas penché plus avant (les journées de 24h, toussa). Mais je n'ai jamais clamé être un expert de C#/.Net donc bien évidemment j'ai pu (du?) rater des choses absoument géniales...
juste pour rajouter: "En tout cas écouter MDI chanter les louanges de la POO et du C# lors du FOSDEM 2003, c'était assez comique (si on est un peu cynique) quand on se souvient que GNOME a été lancé en bonne partie en rejet à C++ ..."
A sa place: objective C, non, trop peu connu, communauté trop "faible". C++: rappelle toi les début de KDE, les difficulté du compilo, le nombre moins important de de développeur et le fait qu'ils se soient basés sur Qt une libre existante comme une base de leur framework (qu'ils ont du changer quelques fois).
Qu'ajouter à ça ? je dit simplement que MDI a surfé sur la vague du C, pour finalement changer d'avis et utiliser un langage OO. Le reproche n'est pas dans le fait qu'il ait changé d'avis, juste que c'était couru d'avance et qu'il aurait du s'en rendre compte. Parce que même moi qui n'aime pas C++, entre programmer en C "objet" et programmer en C++, y'a pas photo -- de toute façon, un langage qui supporte le paradigme de programmation que tu utilises sera toujours plus efficace qu'un langage qui ne le supporte pas, ça paraît pourtant évident !
Sinon, oui, Objective-C était peu connu, mais allez, MDI a suffisamment de charisme pour intéresser les gens. Surtout que franchement, Objective-C est largement plus proche de la notion de "C objet" que C++ ne l'est ...
Le C était à l'époque le langage à la mode, connu de bcp de gens,
Oui, donc c'est bien ce que je disais, MDI a poussé le C par calcul "politique"/marketing plus que par choix technique. Je trouve ça dommage, pour le moins.
... Et tu le dis toi même: tu n'aimes pas le C++, et moi je l'aime bien, parce qu'on peut faire d'affreuse bidouille en C++ (ce qui est exactement ce que je ne voudrais pas dans un projet que je dois maintenir).
Y'a pas comme une légère contradiction, là? de toute façon, le fait que je n'aime pas C++ ne veut pas pour autant dire que je ne l'ai pas utilisé, et que je ne l'utiliserais pas dans le futur : tout simplement, selon moi, un programmeur doit utiliser le bon outil pour le travail qui lui convient. C++ a des atouts, et si j'en ai besoin, je l'utiliserais. Maintenant, j'ai rien vu de mieux pour la programmation objet d'applications graphiques que OpenStep, donc j'utilise GNUstep pour les applis graphiques. Au pire, Qt, vu que les concepts sont franchement inspirés d'OpenStep.
Et finalement, on en revient toujours au même: la critique est si simple, mais toi qu'as tu fait? ;)
Pas autant que je voudrais, mais j'essaie de faire avancer les choses en participant à divers projets et ayant écrit quelques articles dans lmf, bref d'apporter un peu ma pierre à l'édifice.
Je ne connais que de loin C# et .Net, mais bon j'essaierait de me renseigner sur les attributs, à priori ça peut être intéressant...
As-tu des pointeurs sympas traitant du sujet?
Et donc byebye le support de plusieurs langage... ?... De plus ton explication est amha trop simpliste: l'utopie de la transparence, l'utopie d'avoir une couche réseau parfaite, etc...
Oui, on dit au revoir au support de plusieurs langages. Ceci dit, est-ce vraiment dramatique? non. Il est finalement assez rare d'avoir des composants dans un projet, utilisant des langages différents. De plus, rien n'empêche d'utiliser Objective-C comme langage de "glue" permettant d'obtenir les composants, ou éventuellement de faire un pont automatique entre les Distributed Objects (DO) -- objets répartis -- d'OpenStep et Corba -- c'est en fait la voie qui avait été choisie par NeXT à l'époque.
Le point important, c'est surtout qu'il n'y a aucun intérêt à se faire suer avec le modèle lourd de Corba dans la quasi-totalité des cas; se forcer à l'utiliser est alors sacrèment contre-productif selon mon point de vue !! c'est bien pour ça que la solution de KDE de passer par une archi légère est efficace; et c'est bien pour ça que OpenStep avant eux le proposait. Franchement, entre me faire suer à définir un IDL et simplement écrire 2 lignes de plus pour indiquer que j'utilise un objet qui en fait tourne sur une machine à 800 km de là, ben, je sais pas pourquoi, mais je préfère écrire deux lignes.
Accessoirement, l'utopie sur la transparence ou la couche réseau parfaite... heu... de toute façon le problème est identique avec Corba, non?
A l'inverse, le modèle de gestion mémoire utilisé par Objective-C (garbage collector semi-automatique avec référence) est le fait que l'on considère les objets comme des entités "autonomes" auxquelles on envoi des messages (et rien n'empêche d'ailleurs d'envoyer des messages que l'objet ne comprends pas) font que la programmation répartie est tout à fait simple à mettre en place en Objective-C. Maintenant, bon, si tu tiens absolument à passer un temps fou dessus...
n dehors des troll^Wcommentaires sur la mémoire consommée par XP/AmigaOS et le reste du monde (totalement idiot, hors sujet, ...) énormément de commentaires sont du types: ouhhéééoohhéoh, il fait chier MDI, il a choisi de la merde, d'ailleurs X ou Y aurait été bien mieux... ça veut dire quoi: vous êtes meilleurs que MDI? MDI est nul?
En fait, perso, j'avoue que MDI me gonfle, oui :-)
Mais ce que je lui reproche -- et c'est peut être le reproche que pas mal de gens lui font -- c'est de s'être lancé tête baissée sur GNOME en trollant pas mal sur KDE et en mettant en avant le C... alors que franchement, il fallait pas être sorcier pour se rendre compte que non, le C est pas idéal pour programmer des interfaces graphiques, et que, oui, la POO aide un peu. Alors du coup, recoder tout un système OO par dessus C, ben... c'est un peu bourrin, non ? Donc oui, c'est bien une histoire de compromis; mais plus que de compromis techniques, ça a le goût amer de compromis "marketing/politique" (trollez, trollez, il en restera bien quelque chose).
Bon et effectivement, l'amour chez MDI de tout ce que fait Microsoft passe mal, quelque soit le bien fondé ;-) (et ça, j'accorde que c'est un peu nul -- après tout, il peut y avoir des bonnes idées venant de microsoft, .. un jour).
Dans les points positifs, MDI et GNOME ont sûrement contribué à l'existence de la Qt en GPL, et ximian a sorti quelques logiciels intéressants les entreprises et tout et tout.
Dans les points négatifs, ... , on peut quand même se poser la question de savoir si il n'aurait pas mieux valu contribuer à harmony si vraiment la licence Qt lui posait problème, et à KDE ensuite. Et sinon, quitte à ne pas aimer C++ -- que je n'aime pas, mais auquel je reconnais sans peine un certain nombre d'avantages -- il aurait pu choisir un autre langage que C, tel que Objective-C :-P -- voir même, soyons fou, coopérer au projet de bureau du projet GNU existant à l'époque, un truc, souvenez vous, appelé GNUstep. Je suis persuadé que si un dixième du travail qui a été fournit sur GNOME l'avait été sur GNUstep, on aurait aujourd'hui un bureau absolument fabuleux (enfin KDE est pas mal quand même). Mais bon, on ne peut forcer qui que ce soit à bosser sur tel ou tel truc, hein :-)
Mais c'est sûr que la promotion du C était quelque part une voie "facile", caressant dans le sens du poil pas mal de bidouilleurs unix et de programmeurs.
En tout cas écouter MDI chanter les louanges de la POO et du C# lors du FOSDEM 2003, c'était assez comique (si on est un peu cynique) quand on se souvient que GNOME a été lancé en bonne partie en rejet à C++ ...
Bon, je suis partial, c'est sûr, mais je suis d'accord sur la qualité d'Objective-C ;-)
-- plus exactement, ce n'est pas le meilleur langage objet que je connais, mais c'est au moins un de ceux qui a le rapport puissance/simplicité/rapidité le plus intéressant.
Honnêtement je pense que son problème a d'abord été un manque de reconnaissance/compilateur par rapport au C++, et n'oublions pas que pendant pas mal de temps, la POO, c'était pas vraiment à la mode non plus hein...
Sinon, je ne pense pas qu'un développeur C s'adapte réellement facilement à Java, C++ ou C# -- j'aurais plutôt tendance à penser qu'il a l'impression d'une similitude, car la syntaxe ne change pas, et que donc il mette peut être plus de bonne volonté; mais le véritable problème de la POO porte d'abord sur la conception du programme, pas sur le sucre syntaxique utilisé par le langage objet... et franchement, je pense que c'est le problème #1 des programmeurs C qui veulent faire de la POO.
D'ailleurs je trouve que c'est le problème courant avec C++ ... des gens qui continuent à programmer en procédural. Mais bon, C++ est "multi-paradigme" nous dit-on..
Donc certes, on peut éventuellement dire qu'Objective-C est peut être plus dur à appréhender, tout simplement car il encourage la programmation objet, et que la POO, c'est pas évident au début. Mais on peut difficilement dire qu'il soit difficile à appréhender concernant sa syntaxe ! il n'y a qu'UNE addition syntaxique par rapport au C, permettant d'exprimer l'envoi de messages entre objets:
[monObjet reçoitCeMessage]
De plus, je trouve que le fait que la syntaxe soit différente exprime beaucoup mieux que l'on envoi un message et non qu'on fait un appel de fonction sur une structure... j'aurais donc plutôt tendance à penser que cet ajout syntaxique facilite l'écriture et la clareté du code. Accessoirement, le coup des arguments "nommés" est ce qui fait le plus "bizarre" au début en Objective-C, et par contre, c'est vraiment quelque chose qui me manque sur d'autres langages maintenant que je m'y suis habitué; en effet, on prends vite l'habitude de faire "des phrases" :
Les noms des méthodes ObjC (leur signature) étant en fait:
imprimeToi
imprimeToiSur:
imprimeToiSur:enFormat:
... on voit clairement qu'avec une méthode qui prends plus d'un paramètre, mettre les arguments "dans" le nom de la fonction permet une bien meilleur lisibilité du code.
Accessoirement, on peut ne pas utiliser les arguments nommés, il suffit d'utiliser les ":" pour séparer les arguments. M'enfin l'intérêt est limité hein ;-)
Ben heu justement non, tu n'est pas obligé de définir tous les accesseurs à la main, en utilisant setValue:forKey: ou valueForKey:, il utilise un accesseur "par défaut" ... par contre, si tu veux avoir un accesseur qui fait un traitement plus particulier, tu peux toujours le définir.
En Objective-C, tu peux déclarer comme en C++ tes données membres comme public/privées/protégées; et rien ne t'empêche d'avoir un accesseur ayant le même nom que la donnée membre et la retournant (c'est d'ailleurs ce qui est généralement utilisé).
- (NSString*) name {
return name;
}
Accessoirement, à propos des attributs, le principe de "key-value coding" utilisant l'introspection, ça permet des choses très sympas :-)
Grosso modo, tu peut accéder à tes attributs par leur nom, en utilisant deux méthodes,
valueForKey: et setValue:forKey:
Ce qui facilite énormèment tout ce qui est scriptage, bien sûr, mais peut également te simplifier pas mal la vie dans ton code, vu que ça te permet de déterminer dynamiquement l'attribut qui t'intéresse.
Le côté agréable est que l'implémentation par défaut du "key-value coding" dans NSObject utilise des accesseurs si tu les as définis, et sinon accède directement aux données membres.
[^] # Re: Une longue interview de Trolltech
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Une longue interview de Trolltech. Évalué à 1.
Chacun sa religion, mais pour moi c'est bloquant.
Ca y est, on fait comme /. , on lit plus les liens ?
FOX est un toolkit C++ ...
[^] # Re: Une longue interview de Trolltech
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Une longue interview de Trolltech. Évalué à 1.
C'était juste que j'ai, au premier degré, trouvé le commentaire dans la Faq assez amusant : expliquer que Objective-C, un langage dynamique et moins fortement typé que C++, aurait été plus adéquat pour justement avoir un meilleur contrôle du typage...
Quand à la communauté C/C++ ... elle a TOUJOURS été plus importante que celle ObjC. Rien de nouveau sous le soleil hein.
Reste que la qualité d'un langage/toolkit/bidule n'est pas dépendant du nombre. On trouve d'excellents trucs pas très répandus (style, Erlang), et des trucs moisis largement répandus (style, tout le monde à un exemple bien connu en tête). Et on trouve d'excellents trucs répandus (heu... quoique c'est bizarrement assez rare en fait) et des trucs moisis pas répandus du tout.
Selon moi, GNUstep est un excellent toolkit -- même il reste pas mal de boulot à faire. Cependant, le potentiel est là. Et Objective-C est un excellent langage, vraiment agréable (ne serait-ce que les catégories !!).
[^] # Re: Une longue interview de Trolltech
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Une longue interview de Trolltech. Évalué à 1.
Marrant, non ?
[^] # Re: Et DIA ?
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Inkscape : nouveau leader open source du dessin vectoriel ?. Évalué à 7.
Par contre, une UI qui roxorise grave pour faire des diagrammes, c'est ... xfig.
Oui, ce vieux truc tout pas beau (encore qu'il soit possible de le passer en xaw3D, heureusement). Et ben pour faire des diagrammes, c'est nickel -- très rapide à créer, ultra-simple de se créer de nouveaux objets à coller en bibliothèque (très très dur la bibliothèqe -- il suffit de copier les fichiers xfig dans un répertoire; pour faire des sous-entrées, créez des sous-répertoires ... trop dur vraiment !)
Il gère les images, les liens automatiques (vous bougez une figure, les flêches suivent), permet de changer le texte d'une figure sans avoir à "l'ouvrir" (dans le cas d'une figure composée), permet d'exporter dans une tripotée de formats vectoriels différents (dont eps et pdf évidememnt), et accessoirement permet d'écrire du LaTeX dans les champs texte (pratique pour ajouter des formules). Il gère évidemment les calques, et dispose d'une bibliothèque d'objets pas trop mal (même si on pourrait avoir mieux).
Enfin, et surtout, l'UI est vraiment bien foutue, avec les raccourcis-clavier à une touche. Une main sur le clavier, l'autre sur la souris, et hop !
Pour faire du dessin vectoriel, Inkscape/Sodipodi/Sketch sont très bien (Inkscape est vraiment pas mal) ... pour des diagrammes, par contre, je reste à xfig.
Le site principal : http://www.xfig.org(...)
La doc en ligne : http://www.xfig.org/userman/(...) (pas mal faite)
Une capture d'écran : http://www.xfig.org/xfigimages/prettyfig.png(...)
Un schéma électronique de Z80 fait avec xfig : http://www.coprolite.com/art2.html(...)
[^] # Re: Une longue interview de Trolltech
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Une longue interview de Trolltech. Évalué à 3.
[^] # Re: rad for the masses ?
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 3.
[...] qu'est-ce que vous en pensez ?
Utilise GORM et GNUstep.
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 2.
La seule chose, c'est que tu as le CHOIX de typer ou de ne pas typer tes objets.
Tu peux fonctionner simplement en utilisant le type objet de base "id" mais tu peux aussi déclarer tes objets comme étant d'un type d'objet donné (NSString pour les chaînes de caractères par exemple). Accessoirement, tu as tout ce qu'il faut pour vérifier les implémentations des interfaces (protocoles) aussi.
[^] # Re: Sortie de X Window System X11R6.7 de X.Org
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Sortie de X Window System X11R6.7 de X.Org. Évalué à 1.
http://www.freedesktop.org/Main/Desktops(...)
[^] # Re: Sortie de X Window System X11R6.7 de X.Org
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Sortie de X Window System X11R6.7 de X.Org. Évalué à 3.
# Re: GNU LilyPond 2.2.0 : esthétisme de la gravure de musique
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche GNU LilyPond 2.2.0 : esthétisme de la gravure de musique. Évalué à 9.
http://lilypond.org/web/switch/tour.html(...)
Les auteurs ont l'air d'être les héritiers de Don Knuth (auteur de TeX) si on regarde leur amour de la typographie (musicale dans ce cas) :-)
LilyPond est, comme (La)TeX, un moteur de mise en page, qui d'ailleurs utilise LaTeX pour gêrer ses pages et le texte, et METAFONT (le programme de TeX pour créer des fontes vectorielles). Et comme pour LaTeX, des éditeurs graphiques externes existent ...
Les auteurs de LilyPond sont en fait d'avis que de toute façon une interface graphique n'est pas idéal pour ce qu'ils font (et même si je trouve ça difficile à imaginer, vu que je *sais* que c'est effectivement vrai pour le traitement de texte (en bon afficionado de LaTeX que je suis), je leur laisse volontier le bénéfice du doute :-)
Un intéressant essai à lire à propos de la typographie musicale : http://lilypond.org/web/about/automated-engraving/(...)
# Re: LinuxMag de ce mois ci : coup de gueule
Posté par Nicolas Roard (site web personnel) . En réponse au journal LinuxMag de ce mois ci : coup de gueule. Évalué à 2.
Enfin, ça semble un peu comme d'hab -- y'en a qui trouvent le mag trop pointu, d'autres pas assez, d'autres trop orienté programmeur, d'autres couvrant des sujets déjà connus ... On peut quand même imaginer que c'est loin d'être simple de faire un mag qui convienne à tout le monde -- et il y aura toujours des gens que ça n'intéresse pas.
[^] # Re: Voter contre un candidat ?
Posté par Nicolas Roard (site web personnel) . En réponse au journal Voter contre un candidat ?. Évalué à 1.
Parceque, FRANCHEMENT, ça change beaucoup de ce qu'on a en ce moment ? on ne comptes plus le nombre de gens qui votent pour "le moins pire" ...
Au moins ça aurait le mérite de séparer les votes "pour" et les votes "contres". Intéressant pour savoir un peu mieux ou on mets les pieds je trouve.
[^] # Re: Havoc Pennington se pose des questions sur les langages du libre
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 1.
Non, au contraire. C++ est parfait pour certaines choses, mais à mon sens, pour programmer des GUI, ObjC est plus adapté (messages, dynamisme..). Bon après, personnellement je trouve que le framework OpenStep est justement au top pour ça, car élégant et exploitant bien ObjC. Mais bon, quitte à réinventer la roue pour un toolkit graphique, oui, ObjC me semble une meilleure idée que C++.
Ah, quand je parlais d'améliorer l'AppKit, je voulait dire d'améliorer l'implémentation actuelle de GNUstep hein... l'AppKit en lui même (design) ne nécessite pas vraiment de bouleversement -- Apple ne l'a d'ailleurs pas vraiment touché ... juste ajouté quelques nouveaux widgets (si, ils ont ajouté NSDocument également, mais bon..).
[^] # Re: Havoc Pennington se pose des questions les langages du libre
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 2.
Yep, mais bon, peu de monde les utilisent. C'est assez barbare à mon avis, il est beaucoup plus sympa d'attaquer Cocoa en Objective-C qu'en Java.
Ceci dit, GNUstep propose également des bindings Java hein.
[^] # Re: Havoc Pennington se pose des questions sur les langages du libre
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 1.
Heu... franchement, l'intérêt serait très limité. Pourquoi créer une GUI spécifique Gnome alors que l'ApplicationKit existe ? il est laaaargement plus intéressant de continuer à bosser sur l'AppKit pour l'améliorer que d'implémenter un framework graphique inspiré de gnome, hein. L'AppKit est un foutu bon framework -- voire même, c'est ce qu'il y a de plus intéressant dans OpenStep -- FoundationKit est sympa, mais le truc qui tue, c'est l'AppKit hein.
Il faut également que l'ObjC permet la communication inter-process, la distribution d'objets de manière quasi-transparente (plus facile que le Net-remoting de .NET).
Il faut également noter j'imagine ? :-)
[^] # Re: Mon hacker préféré
Posté par Nicolas Roard (site web personnel) . En réponse au sondage Mon hacker préféré. Évalué à 1.
Francement, c'est mon hacker prefere -- ce qu'il avait fait avec Spectre, ca, c'etait quand meme un sacre tour de force. Et puis tout simplement, ses articles etaient fabuleux, completement dans l'ethique hacker. Il a d'ailleurs ecrit un article assez connu sur Tesla, le plus grand des hackers selon lui :)
[^] # Re: alternatives à développer et essayer.
Posté par Nicolas Roard (site web personnel) . En réponse au journal Un monde pour tous sauf.... Évalué à 3.
Comme Arnaud Montebourg et la C6R par exemple ?
http://www.c6r-fr.org/(...)
[^] # Re: XAML et l'avenir de GNOME
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 3.
D'un autre cote, est-ce qu'on doit reellement lui reprocher ? en etant objectif, avoir un responsable de projet "communicatif", ca aide sacrement le projet en question... et on ne peut nier qu'une bonne partie de l'interet que gnome a suscite a ete du a MDI. Il existe pas mal de projets libres qui ont au contraire du mal a avancer a cause d'un manque de reconnaissance/marketing, mais qui techniquement sont meilleurs que d'autres plus connus. La technique ne fait pas tout -- avec le LL on ne change pas de planete, le facteur humain reste important :)
[^] # Re: XAML et l'avenir de GNOME
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
[^] # Re: XAML et l'avenir de GNOME
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 2.
Ce que je veut dire, c'est que pour un 'bureau' ou l'on veut avoir des composants graphiques externalises, on a pas forcement besoin de tout ce que propose Corba. Le point qui est eventuellement litigieux est la possibilite d'etre independant du langage -- mais ce que je remarque, c'est que tres souvent, le langage utilise est le meme pour l'ensemble des applis/composants.
La tres tres grande majorite des applis KDE sont en C++, la tres tres grande majorite des applis GNOME en C, et cote GNUstep, je connais pas d'appli (graphique, cote serveur il y en a...) qui utilisent par exemple les bindings Java. Mixer differents langages est l'exception plus que la norme.
A mon avis ca s'explique par le fait que les bibliotheques sont d'abord faites pour un langage donne et tirent partie des avantages du langage, et que finalement, il est souvent prefererable d'utiliser le langage "reconnu" si l'on veut tirer partie de toutes les capacitees proposees. Ca peut aussi etre simplement un lag entre les versions des librairies accessibles par les bindings et les versions courante.. mais le resultat est le meme.
Enfin, pour les rares cas ou l'on veut effectivement utiliser un autre langage, encapsuler ton code (utilisant un autre langage que le "principal") dans un composant 'leger' code lui en utilisant le langage dans lequel les libs sont codes n'est pas bien complique.
Accessoirement, le coup d'utiliser du C parce que ca facilite les bindings est plus ou moins vrai... certes, ca peut faciliter, mais bon, KDE propose par exemple des bindings pour une foultitude de langages, et meme GNUstep, avec peu developpeurs, propose des bindings en Java, Ruby, Scheme..
Bref, emmerder tout le monde (utiliser un langage procedural pour faire de la POO) et reinventer la roue (C "objet") pour cette raison (facilite des bindings) est plutot une decision pas si justifiee, au final, non ?
Dans l'absolu, oui. En étant réaliste: c'est inévitable, l'histoire de compromis à nouveau...
Oui, mais c'est ce "compromis" que je trouve vaseux, justement. Mais bon, c'est juste mon opinion, je trouve contre-productif de faire du developpement objet en C, c'est tout.
ps: tu connaissais Miguel De Icaza avant Gnome? moi pas.
Oui, il avait ecrit midnight commander.
[^] # Re: XAML et l'avenir de GNOME
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
Pas exactement; mon argument était plutôt, certes Corba apporte des trucs sympas, mais en pratique, a-t-on réellement besoin de tout ça ? dans la plupart des cas, non. Utiliser Corba est donc trop lourd pour un intérêt assez limité. Dans ce cas, je trouve qu'utiliser un modèle plus léger est plus efficace et sensé.
Là ou je suis moins d'accord c'est sur le fait de pouvoir utiliser un composant depuis n'importe quel langage: en local c'est déjà assez courant (regarde le nombre de binding c++, python, perl, php, whatever qu'il existe pour des lib c... alors qu'avec un format "standard" on pourrait s'en passer). Mais une fois en remoting, c'est capital il me semble: tu ne peux pas contraindre tout tes projets à être en objective-C! Ce langage est sous doute adapté à certaines choses, mais le sera moins à d'autre, particulièrement en tenant compte de l'existant.
Non, je maintiens ce que je dis : dans un programme donné, il est rare d'avoir plusieurs langages. Les bindings existent, certes, mais sont-ils largement employés? pas tant que ça. Enfin, je ne dit pas du tout qu'utiliser DO est la panacée qui répondra à tous les besoins, simplement que DO est idéal pour utiliser des objets répartis dans ton application, si tu programmes en Objective-C.
Et accessoirement, faire un pont DO <-> Corba ne serait pas si compliqué, vraiment. Personne ne l'a implémenté dans le libre, parce que l'intérêt est honnêtement limité ... mais c'est ce que NeXT avait fait (début des années 90).
Pour synthétiser, intellectuellement, un modèle de composant qui fonctionne avec n'importe quoi, à la Corba, peut être intéressant. Mais en pratique, tu vas utiliser ça dans 1% des cas... il est logique alors de privilégier une solution plus simple -- mais plus efficace. C'est que font GNUstep et KDE. De toute façon, rien n'empêche de réaliser des ponts vers corba si vraiment tu y tient !
Pour le reste, c'est soit des répétions, soit de la mauvaise fois (tu ne connais ni C# ni .NET mais c'est pas une bonne idée...)
Evidemment que je suis un peu de mauvaise foi :-)
mais bon, je n'ai pas dit non plus que je ne connais absolument pas C# ou .Net -- juste que ce que j'en sais ne m'a pas intéressé et donc que je ne m'y suis pas penché plus avant (les journées de 24h, toussa). Mais je n'ai jamais clamé être un expert de C#/.Net donc bien évidemment j'ai pu (du?) rater des choses absoument géniales...
juste pour rajouter: "En tout cas écouter MDI chanter les louanges de la POO et du C# lors du FOSDEM 2003, c'était assez comique (si on est un peu cynique) quand on se souvient que GNOME a été lancé en bonne partie en rejet à C++ ..."
A sa place: objective C, non, trop peu connu, communauté trop "faible". C++: rappelle toi les début de KDE, les difficulté du compilo, le nombre moins important de de développeur et le fait qu'ils se soient basés sur Qt une libre existante comme une base de leur framework (qu'ils ont du changer quelques fois).
Qu'ajouter à ça ? je dit simplement que MDI a surfé sur la vague du C, pour finalement changer d'avis et utiliser un langage OO. Le reproche n'est pas dans le fait qu'il ait changé d'avis, juste que c'était couru d'avance et qu'il aurait du s'en rendre compte. Parce que même moi qui n'aime pas C++, entre programmer en C "objet" et programmer en C++, y'a pas photo -- de toute façon, un langage qui supporte le paradigme de programmation que tu utilises sera toujours plus efficace qu'un langage qui ne le supporte pas, ça paraît pourtant évident !
Sinon, oui, Objective-C était peu connu, mais allez, MDI a suffisamment de charisme pour intéresser les gens. Surtout que franchement, Objective-C est largement plus proche de la notion de "C objet" que C++ ne l'est ...
Le C était à l'époque le langage à la mode, connu de bcp de gens,
Oui, donc c'est bien ce que je disais, MDI a poussé le C par calcul "politique"/marketing plus que par choix technique. Je trouve ça dommage, pour le moins.
... Et tu le dis toi même: tu n'aimes pas le C++, et moi je l'aime bien, parce qu'on peut faire d'affreuse bidouille en C++ (ce qui est exactement ce que je ne voudrais pas dans un projet que je dois maintenir).
Y'a pas comme une légère contradiction, là? de toute façon, le fait que je n'aime pas C++ ne veut pas pour autant dire que je ne l'ai pas utilisé, et que je ne l'utiliserais pas dans le futur : tout simplement, selon moi, un programmeur doit utiliser le bon outil pour le travail qui lui convient. C++ a des atouts, et si j'en ai besoin, je l'utiliserais. Maintenant, j'ai rien vu de mieux pour la programmation objet d'applications graphiques que OpenStep, donc j'utilise GNUstep pour les applis graphiques. Au pire, Qt, vu que les concepts sont franchement inspirés d'OpenStep.
Et finalement, on en revient toujours au même: la critique est si simple, mais toi qu'as tu fait? ;)
Pas autant que je voudrais, mais j'essaie de faire avancer les choses en participant à divers projets et ayant écrit quelques articles dans lmf, bref d'apporter un peu ma pierre à l'édifice.
http://freshmeat.net/~nicolasroard/(...)
http://www.nongnu.org/backbone/(...)
http://www.nongnu.org/latexfr/(...)
http://www.roard.com/docs/(...)
[^] # Re: XAML et l'avenir de GNOME
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 2.
As-tu des pointeurs sympas traitant du sujet?
Et donc byebye le support de plusieurs langage... ?... De plus ton explication est amha trop simpliste: l'utopie de la transparence, l'utopie d'avoir une couche réseau parfaite, etc...
Oui, on dit au revoir au support de plusieurs langages. Ceci dit, est-ce vraiment dramatique? non. Il est finalement assez rare d'avoir des composants dans un projet, utilisant des langages différents. De plus, rien n'empêche d'utiliser Objective-C comme langage de "glue" permettant d'obtenir les composants, ou éventuellement de faire un pont automatique entre les Distributed Objects (DO) -- objets répartis -- d'OpenStep et Corba -- c'est en fait la voie qui avait été choisie par NeXT à l'époque.
Le point important, c'est surtout qu'il n'y a aucun intérêt à se faire suer avec le modèle lourd de Corba dans la quasi-totalité des cas; se forcer à l'utiliser est alors sacrèment contre-productif selon mon point de vue !! c'est bien pour ça que la solution de KDE de passer par une archi légère est efficace; et c'est bien pour ça que OpenStep avant eux le proposait. Franchement, entre me faire suer à définir un IDL et simplement écrire 2 lignes de plus pour indiquer que j'utilise un objet qui en fait tourne sur une machine à 800 km de là, ben, je sais pas pourquoi, mais je préfère écrire deux lignes.
Accessoirement, l'utopie sur la transparence ou la couche réseau parfaite... heu... de toute façon le problème est identique avec Corba, non?
A l'inverse, le modèle de gestion mémoire utilisé par Objective-C (garbage collector semi-automatique avec référence) est le fait que l'on considère les objets comme des entités "autonomes" auxquelles on envoi des messages (et rien n'empêche d'ailleurs d'envoyer des messages que l'objet ne comprends pas) font que la programmation répartie est tout à fait simple à mettre en place en Objective-C. Maintenant, bon, si tu tiens absolument à passer un temps fou dessus...
n dehors des troll^Wcommentaires sur la mémoire consommée par XP/AmigaOS et le reste du monde (totalement idiot, hors sujet, ...) énormément de commentaires sont du types: ouhhéééoohhéoh, il fait chier MDI, il a choisi de la merde, d'ailleurs X ou Y aurait été bien mieux... ça veut dire quoi: vous êtes meilleurs que MDI? MDI est nul?
En fait, perso, j'avoue que MDI me gonfle, oui :-)
Mais ce que je lui reproche -- et c'est peut être le reproche que pas mal de gens lui font -- c'est de s'être lancé tête baissée sur GNOME en trollant pas mal sur KDE et en mettant en avant le C... alors que franchement, il fallait pas être sorcier pour se rendre compte que non, le C est pas idéal pour programmer des interfaces graphiques, et que, oui, la POO aide un peu. Alors du coup, recoder tout un système OO par dessus C, ben... c'est un peu bourrin, non ? Donc oui, c'est bien une histoire de compromis; mais plus que de compromis techniques, ça a le goût amer de compromis "marketing/politique" (trollez, trollez, il en restera bien quelque chose).
Bon et effectivement, l'amour chez MDI de tout ce que fait Microsoft passe mal, quelque soit le bien fondé ;-) (et ça, j'accorde que c'est un peu nul -- après tout, il peut y avoir des bonnes idées venant de microsoft, .. un jour).
Dans les points positifs, MDI et GNOME ont sûrement contribué à l'existence de la Qt en GPL, et ximian a sorti quelques logiciels intéressants les entreprises et tout et tout.
Dans les points négatifs, ... , on peut quand même se poser la question de savoir si il n'aurait pas mieux valu contribuer à harmony si vraiment la licence Qt lui posait problème, et à KDE ensuite. Et sinon, quitte à ne pas aimer C++ -- que je n'aime pas, mais auquel je reconnais sans peine un certain nombre d'avantages -- il aurait pu choisir un autre langage que C, tel que Objective-C :-P -- voir même, soyons fou, coopérer au projet de bureau du projet GNU existant à l'époque, un truc, souvenez vous, appelé GNUstep. Je suis persuadé que si un dixième du travail qui a été fournit sur GNOME l'avait été sur GNUstep, on aurait aujourd'hui un bureau absolument fabuleux (enfin KDE est pas mal quand même). Mais bon, on ne peut forcer qui que ce soit à bosser sur tel ou tel truc, hein :-)
Mais c'est sûr que la promotion du C était quelque part une voie "facile", caressant dans le sens du poil pas mal de bidouilleurs unix et de programmeurs.
En tout cas écouter MDI chanter les louanges de la POO et du C# lors du FOSDEM 2003, c'était assez comique (si on est un peu cynique) quand on se souvient que GNOME a été lancé en bonne partie en rejet à C++ ...
[^] # Re: XAML et l'avenir de GNOME
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 2.
-- plus exactement, ce n'est pas le meilleur langage objet que je connais, mais c'est au moins un de ceux qui a le rapport puissance/simplicité/rapidité le plus intéressant.
Honnêtement je pense que son problème a d'abord été un manque de reconnaissance/compilateur par rapport au C++, et n'oublions pas que pendant pas mal de temps, la POO, c'était pas vraiment à la mode non plus hein...
Sinon, je ne pense pas qu'un développeur C s'adapte réellement facilement à Java, C++ ou C# -- j'aurais plutôt tendance à penser qu'il a l'impression d'une similitude, car la syntaxe ne change pas, et que donc il mette peut être plus de bonne volonté; mais le véritable problème de la POO porte d'abord sur la conception du programme, pas sur le sucre syntaxique utilisé par le langage objet... et franchement, je pense que c'est le problème #1 des programmeurs C qui veulent faire de la POO.
D'ailleurs je trouve que c'est le problème courant avec C++ ... des gens qui continuent à programmer en procédural. Mais bon, C++ est "multi-paradigme" nous dit-on..
Donc certes, on peut éventuellement dire qu'Objective-C est peut être plus dur à appréhender, tout simplement car il encourage la programmation objet, et que la POO, c'est pas évident au début. Mais on peut difficilement dire qu'il soit difficile à appréhender concernant sa syntaxe ! il n'y a qu'UNE addition syntaxique par rapport au C, permettant d'exprimer l'envoi de messages entre objets:
[monObjet reçoitCeMessage]
De plus, je trouve que le fait que la syntaxe soit différente exprime beaucoup mieux que l'on envoi un message et non qu'on fait un appel de fonction sur une structure... j'aurais donc plutôt tendance à penser que cet ajout syntaxique facilite l'écriture et la clareté du code. Accessoirement, le coup des arguments "nommés" est ce qui fait le plus "bizarre" au début en Objective-C, et par contre, c'est vraiment quelque chose qui me manque sur d'autres langages maintenant que je m'y suis habitué; en effet, on prends vite l'habitude de faire "des phrases" :
[monObjet imprimeToi];
[monObjet imprimeToiSur: imprimante];
[monObjet imprimeToiSur: imprimante enFormat: a4];
ce qui corresponds en C++ à :
monObjet.imprimeToi ();
monObjet.imprimeToiSur (imprimante);
monObjet.imprimeToiSurEnFormat (imprimante, a4);
Les noms des méthodes ObjC (leur signature) étant en fait:
imprimeToi
imprimeToiSur:
imprimeToiSur:enFormat:
... on voit clairement qu'avec une méthode qui prends plus d'un paramètre, mettre les arguments "dans" le nom de la fonction permet une bien meilleur lisibilité du code.
Accessoirement, on peut ne pas utiliser les arguments nommés, il suffit d'utiliser les ":" pour séparer les arguments. M'enfin l'intérêt est limité hein ;-)
[^] # Re: XAML et l'avenir de GNOME
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
[^] # Re: XAML et l'avenir de GNOME
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 2.
En Objective-C, tu peux déclarer comme en C++ tes données membres comme public/privées/protégées; et rien ne t'empêche d'avoir un accesseur ayant le même nom que la donnée membre et la retournant (c'est d'ailleurs ce qui est généralement utilisé).
- (NSString*) name {
return name;
}
Accessoirement, à propos des attributs, le principe de "key-value coding" utilisant l'introspection, ça permet des choses très sympas :-)
Grosso modo, tu peut accéder à tes attributs par leur nom, en utilisant deux méthodes,
valueForKey: et setValue:forKey:
- (id) valueForKey: (NSString*) key;
- (void) setValue: (id) value forKey: (NSString*) key;
Ce qui facilite énormèment tout ce qui est scriptage, bien sûr, mais peut également te simplifier pas mal la vie dans ton code, vu que ça te permet de déterminer dynamiquement l'attribut qui t'intéresse.
Le côté agréable est que l'implémentation par défaut du "key-value coding" dans NSObject utilise des accesseurs si tu les as définis, et sinon accède directement aux données membres.
Plus d'infos ici : http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueC(...)