Amos Wenger a écrit 91 commentaires

C'est effectivement de ça que je parlais.

Pour ce qui est du typage, ooc est déjà sensiblement plus malin/contraignant qu'un simple compilateur C. Si on déclare les variables avec le bon type, le compilateur vérifie tous les appels fonctions et accès aux champs.

La seule manière de contourner cette sécurité est de faire un méchant cast (seuls les casts ne sont pas vérifiés). Donc en gros, le programmeur a potentiellement les problèmes qu'il mérite / est puni selon les risques qu'il prend.

Je sais pas quelle doc tu es en train de lire, mais en tout cas le Guide de référence du langage [http://ooc-lang.org/doc/langref/book1.htm] parle également de ArrayList et SparseList.
Pour les maps & compagnie, il va falloir attendre la 0.3, qui ne saurait tarder =) Je rappelle au passage que tous ceux qui ont une âme charitable et souhaitent contribuer du code sont plus que les bienvenus. Tout le monde en profite.

(comme le fait remarquer アントニ ドミ, j'ai suivi ton conseil et ajouté un petit exemple qui montre quelques possibilités du langage)

Je proteste. Donnez-moi le numéro de norme ISO concernant les hello world, et je normaliserais. Pas avant. =)

Non. Tout est implémenté (pour l'instant) avec des pointeurs sur des fonctions. Donc, quand tu construis le premier objet Wheel, il est assigné au champ "roll" dans sa structure de classe l'adresse de la fonction roll tel qu'implémenté dans Wheel.
Quand tu construis le premier objet BetterWheel, il est assigné au champ "roll" dans sa structure de class l'adresse de la fonction roll tel qu'implémenté dans BetterWheel. Ainsi, quand w2.roll est traduit par le compilateur en w2->_class->_roll() cela référence la bonne version.
L'assignation des pointeurs de méthodes dans les structures de classes n'est faite qu'une seule fois par classe, et toutes les structures d'objet pointent vers la meme structure de classe, donc il n'y a quasiment aucun gaspillage mémoire ni CPU.

A peu près dans tous les chapitres du guide de référence du langage, il y a des exemples de code. [http://ooc-lang.org/doc/langref/book1.htm]

Sinon, la meilleure ressource pour les exemples reste le dépôt git: [http://github.com/amoswenger/ooc/tree/4a977fe092e18bd9cdaffe(...)]

Et pour la route, un petit hello world fait maison:
func main {
printf("Hello, Linuxfr world =)\n");
}


Je ne sais pas comment est implémenté le passage de messages en Objective-C, mais je sais que certains langages ont un algorithme de recherche de la méthode a appeler (en fonction des arguments et du type). En ce qui concerne ooc, l'appel d'une fonction membre implique seulement deux déréférencements de pointeurs, donc c'est relativement peu coûteux.

Ceci dit, je retiens le commentaire et c'est effectivement une des choses a améliorer avant ooc 0.3

Pour les intéressés, voici le rapport de bug correspondant: [https://bugs.launchpad.net/ooc-language/+bug/392551]

Ma foi, le monde est un endroit bien dangereux. La sécurité implique toujours un coût, et "presque aussi vite que du C" n'est pas vraiment une mesure objective. Je serais assez intéressé par une série de benchmarks C vs Objective-C aussi peu biaisés que possible.

C'est une excellente question, merci de l'avoir posée (si, si). En fait, pour l'instant, la définition du langage et l'implémentation de référence du compilateur évoluent en même temps. Il se trouve que la version 0.2 de chacun d'entre eux correspond a la "sortie" du "Language Reference Guide", [http://ooc-lang.org/doc/langref/book1.htm]. Il serait plus juste de dire que sont sortis en même temps "le brouillon 0.2 de la spécification du langage" et "la version 0.2 instable de l'implémentation de référence du compilateur". Mais ça faisait un peu long comme titre de dépêche.

Argl, toutes mes excuses, passer sa nuit a rédiger la même nouvelle pour des sites officiels, ca laisse des traces :X Sincèrement désolé. (/me cherche le lien "Editer la dépêche")

Comme le site officiel le précise, Vala et ooc sont très proches en philosophie. La différence fondamentale est que Vala est basé entièrement sur la GLib et son modèle objet. Cela apporte des avantages considérables (librairie mature et très bien conçue), mais aussi une dépendance d'un poids non-négligeable.

Par contraste, ooc se base uniquement sur la librairie standard C. Cela est avantageux tant en terme de taille que de déploiement sur des plateformes disons.. exotiques (je pense en particulier a Haiku, réécriture libre du défunt BeOS).

Ceci dit, Vala est un excellent langage que je recommande également de tester. Il est sans aucun doute l'avenir du développement des applications Gnome/GTK, vu son fort degré d'intégration avec ces librairies.

N'ayant pas réellement testé Objective-C ces derniers temps j'ai justement comparé un peu avec ooc en se basant sur la page Wikipédia d'[[Objective-C]]. On peut tout de même dire que les deux langages ont un public cible qui se ressemble.

Voici les quelques différences qui me sautent aux yeux:
- Objective-C utilise l'envoi de messages au lieu de l'appel de méthode
- Objective-C est un sur-ensemble strict du C, donc il hérite de ses bizarreries syntaxiques.
- Objective-C met l'accent sur les décisions au temps de l'execution, alors qu'ooc essaie d'attraper les erreurs au temps de la compilation.
- Objective-C n'est pas traduit en C mais compilé directement. Parmi les inconvénients, cela veut dire qu'il faut porter le compilateur sous toutes les plateformes visées. Dans le cas d'ooc, on peut utiliser le compilateur ooc pour traduire .ooc -> .c/.h, puis utiliser gcc pour cross-compiler sur un des 50+ architectures qu'il supporte.

Enfin, ooc est inspiré en partie de Java, lui-meme inspire (entre autres) d'Objective-C, lui-meme inspire de Smalltalk. Concrètement, Objective-C est un langage mature qui apparamment ne changera plus beaucoup. Cela permet une grande stabilité, mais le langage est condamné a rester dans ses habitudes: il est trop tard pour tirer les leçons du passé (par exemple, gcc semble ne pas supporter totalement ObjC 2.0). Par contraste, ooc est un jeune galopin qui essaie d'apprendre de ses grands-parents. Il est largement encore temps de s'impliquer et d'influer sur le design.

Très juste. Mais il faut bien commencer quelque part, non ?

Il est vrai que pour l'instant, la "sécurité" n'a pas ete un objectif prédominant dans l'implémentation. Cependant, rien dans le design du langage/du compilateur ne s'oppose a l'intégration de mécanismes de contrôle tel qu'on peut trouver dans OCaml, par exemple.

Malheureusement la sécurité a un coût performance, c'est pour ça que je pense laisse l'option de désactiver les (futurs) mécanismes de sécurité/vérification dans les prochaines versions. (Exemple: activé pendant le développement/débuggage, désactivé en environnement ou la performance est critique)

Après, il faut garder a l'esprit qu'aucun langage n'est la réponse définitive a tous les besoins. Quant a coder "sécurisé", pourquoi ne pas choisir Ada?

En résumé, pour continuer la série des métaphores, je dirais que: "ooc still allows you to shoot yourself in the foot, but with a cooler weapon" ;)

aaaaaaaargl redhat sors de ce corps.
pour ma part, j'ai tout resolu a grand coup de "equery check". (il y a surement mieux comme methode, mais c'est ce qui m'est venu a l'esprit sur le moment.)

quitte a etre le premier a oser le poster, oui je viens de tester (en pleine connaissance de cause) "rm -rf /*" (zsh etant trop malin pour le "rm -rf /", j'etais curieux de savoir s'il detecterait ca aussi), et comment dire.. j'ai pas ete assez rapide du Ctrl+C, et /bin etant le premier repertoire par ordre alphabetique..

..enfin bref ca fait bizarre de se retrouver sans "ls" et compagnie ^^. heureusement qu'il y a le minimal install CD de gentoo et chroot a portee de main. c'est peut etre l'occase de reinstall en 64 bits, quand j'en aurais marre de reparer les degats a la main..