Pour répondre à tes questions une par une:
* Oui, ooc est une alternative sérieuse au D dans ton cas, et je suis absolument motivé de corriger le générateur de code si le C produit ne compile pas pour un target ARM (j'ai l'habitude des plateformes *très comfortables*, e.g. Gentoo Linux sur un x86, donc j'ai des fois tendance à oublier que dans le monde réel il y a plus de contraintes.)
* En effet, le D est un langage très bien conçu (à mon avis) et par des gens sérieux, mais les implémentations libres laggent méchamment derrière DMD, tout ça à cause de leur état d'esprit semi-propriétaire et c'est vraiment dommage.
* Les delegates sont prévus, c'est de plus très rapide a implémenter, donc pas de souci de ce côté là.
* Pour les chaines ASCII/UTF-16, etc. je te propose une solution que j'envisageais depuis longtemps: annoter les fonctions C, pour dire à quel type de String elles s'attendent, et permettre de surcharger le cast, pour passer par des fonctions de conversions. Qu'en penses-tu ?
* Pour les pointeurs de fonction membres, je n'ai que survolé le sujet dans le language reference guide, mais mes plans sont assez précis. Peux-tu vérifier que les créateurs de LibJIT disent vrai quand ils prétendent supporter la plateforme ARM? (exemple essayer de compiler leurs exemples dessus). C'est par ici que ça se passe: [http://code.google.com/p/libjit-linear-scan-register-allocat(...)] Pourquoi un Just-In-Time assembler, me direz-vous? Pour faire du currying en ooc [http://en.wikipedia.org/wiki/Currying] c'est à dire "créer en temps réel une fonction avec qq arguments fixés" et je pense bien sur au premier argument, c'est a dire le pointeur vers la structure de l'objet duquel on appelle la fonction. Bien sur il faudrait benchmarker l'utilisation CPU/Mémoire additionelle que cela implique, mais ça serait *tellement* pratique que je pense que c'est intéressant tout de même. L'implémentation de la même méthode avec GNU lightning marchait a merveille =)
Si tout ce que je raconte la haut semble te convenir, je te conseille de prendre le chemin du bug tracker d'ooc [http://bugs.launchpad.net/ooc-language] et de faire un rapport de bug par feature manquante (delegates, strings UTF-16, pointeurs de fonctions membres). Cela permettra de suivre l'évolution des discussions et de l'implémentation plus facilement.
[^] # Re: Super un nouveau langage
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 3.
Pour répondre à tes questions une par une:
* Oui, ooc est une alternative sérieuse au D dans ton cas, et je suis absolument motivé de corriger le générateur de code si le C produit ne compile pas pour un target ARM (j'ai l'habitude des plateformes *très comfortables*, e.g. Gentoo Linux sur un x86, donc j'ai des fois tendance à oublier que dans le monde réel il y a plus de contraintes.)
* En effet, le D est un langage très bien conçu (à mon avis) et par des gens sérieux, mais les implémentations libres laggent méchamment derrière DMD, tout ça à cause de leur état d'esprit semi-propriétaire et c'est vraiment dommage.
* Les delegates sont prévus, c'est de plus très rapide a implémenter, donc pas de souci de ce côté là.
* Pour les chaines ASCII/UTF-16, etc. je te propose une solution que j'envisageais depuis longtemps: annoter les fonctions C, pour dire à quel type de String elles s'attendent, et permettre de surcharger le cast, pour passer par des fonctions de conversions. Qu'en penses-tu ?
* Pour les pointeurs de fonction membres, je n'ai que survolé le sujet dans le language reference guide, mais mes plans sont assez précis. Peux-tu vérifier que les créateurs de LibJIT disent vrai quand ils prétendent supporter la plateforme ARM? (exemple essayer de compiler leurs exemples dessus). C'est par ici que ça se passe: [http://code.google.com/p/libjit-linear-scan-register-allocat(...)] Pourquoi un Just-In-Time assembler, me direz-vous? Pour faire du currying en ooc [http://en.wikipedia.org/wiki/Currying] c'est à dire "créer en temps réel une fonction avec qq arguments fixés" et je pense bien sur au premier argument, c'est a dire le pointeur vers la structure de l'objet duquel on appelle la fonction. Bien sur il faudrait benchmarker l'utilisation CPU/Mémoire additionelle que cela implique, mais ça serait *tellement* pratique que je pense que c'est intéressant tout de même. L'implémentation de la même méthode avec GNU lightning marchait a merveille =)
Si tout ce que je raconte la haut semble te convenir, je te conseille de prendre le chemin du bug tracker d'ooc [http://bugs.launchpad.net/ooc-language] et de faire un rapport de bug par feature manquante (delegates, strings UTF-16, pointeurs de fonctions membres). Cela permettra de suivre l'évolution des discussions et de l'implémentation plus facilement.