Re: [Gambas-user-fr] Quelques Idées

[Fabien B. <gam...@gm...>]

Le 9 février 2011 17:41, Benoît Minisini
<ga...@us...> a écrit :
>> Bonjour à tous,
>>
>> Quand je développe des composants pour Gambas, étant habitué également au
>> C++, je ressens quelques petits "manques" dans le langage comme par exemple
>>
>>
>> - La surcharge des fonctions : si vous ne connaissez pas, il s'agit de
>> pouvoir implémenter deux fonctions qui ont le même nom, mais pas la même
>> signature (les arguments et la valeur de retour). Un exemple, une fonction
>> qui prend un tableau de valeurs. Si l'utilisateur fait Fonction([1,4,9,4]),
>> le tableau sera un Integer[]. Mais si il met la moindre virgule, la tableau
>> est, je crois, transformé en Float[]. Cela fait donc deux types de
>> paramètres différents.
>>
>
> La surcharge de fonctions à la C++ étant un cauchemar syntaxique à
> implémenter, et une complexité supplémentaire pour la personne qui débogue, je
> ne pense pas que ça serve réellement à quelque chose.
>
> D'autre part, pour ce qui concerne ton exemple, Gambas 3 convertit désormais
> les types de tableaux entre eux de manière automatique. Si tu passes un
> Integer[] à un argument de type Float[], l'Integer[] sera automatiquement
> converti en Float[].
>
>> - Ré-implémenter les tableaux faits à la volée par l'interpréteur. Il est
>> actuellement possible en Gambas de ré-implémenter toutes les classes ...
>> sauf celles-ci, ce qui oblige par exemple à créer une "classe-tableau",
>> par exemple MonObjetList, ce qui oblige à ré-implémenter les fonctions
>> telles que Add(), Sort() ... et empêche de faire des tableaux natifs
>> (exemple : [monObjet1, monObjet2, monObjet3])
>
> Est-ce que tu peux être plus clair ? Est-ce que tu veux dire que "Inherits
> MyClass[]" ne fonctionne pas ?
>
>>
>> - Les variables n'importe où dans le code : là je crois que c'est assez
>> clair, disons que personnellement j'aime pas remonter tout en haut de ma
>> fonction pour déclarer une nouvelle variable ... surtout si celle-ci ne
>> sera utile qu'une fois sur 100 car elle ne sera utilisée que dans un bout
>> de bloc IF ou FOR.
>
> Pour les variables de boucle, je suis d'accord, c'est un peu pénible. Par
> contre, pour celui qui relit un programme ou le débogue, avoir des variables
> n'importe où est un cauchemar. Donc je préfère les obliger à rester en haut de
> la fonction.

il faudrait juste que l'ide puisse les ajouter si elles n'existent pas
ou proposer de les enlever (les declarations), idem pour les fonctions


> Comme on passe 80% du temps de développement à déboguer, j'ai tendance à
> privilégier le débogage.
>
>>
>> - Et - là je rêve, mais bon - faire un compilateur qui sorte un véritable
>> exécutable Linux. Je tiens l'idée d'un vieux langage basic de l'époque, qui
>> avait un interpréteur pour un coder-tester rapide et un super débogage en
>> direct comme le fait actuellement Gambas (et d'ailleurs au passage le
>> débogueur intégré à l'IDE est super ;) ), et aussi un compilateur qui
>> compilait le code pour le rendre exécutable sur n'importe quelle
>> plate-forme sans runtime (juste quelques bibliothèques). Ainsi, on prenait
>> les avantages des deux méthodes sans les inconvénients. Sur le principe
>> c'est simple, mais je me doute bien que ça doit être très très complexe à
>> mettre en place.
>
> Oui, c'est compliqué un vrai compilateur. Je n'ai jamais fait (j'ai déjà fait
> un assembleur), et puis en réalité ce n'est pas vraiment ce qu'il faut.
>
> L'intérêt d'un interpréteur, c'est la compacité du code exécutable. Si on
> compile tout, ça bouffe une quantité de ram conséquente.
>
> Ce qu'il est envisageable de faire en ce qui me concerne, ce serait de
> traduire en C des fonctions du projet Gambas désignées par le programmeur, de
> les compiler avec gcc (s'il est installé sur la machine) en une librairie
> partagée qui serait chargée par l'interpréteur a l'exécution. En outre Gambas
> est censé être indépendant de l'architecture, ce qui pose un problème
> supplémentaire.
>
> Mais si quelqu'un sait faire un compilateur (just in time, ou pas) et veut
> passer un ou deux ans à le développer, pourquoi pas ? :-)
>
>>
>> Serait-ce envisageable d'implémenter tout cela dans Gambas 3 ?
>>
>> Cordialement,
>
> Je veux sortir la release candidate bientôt sous peu, donc ça m'étonnerait !
> :-)
>
> Cordialement,
>
> --
> Benoît Minisini
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Gambas-user-fr mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gambas-user-fr
>



-- 
Fabien Bodard