Sinon, c'est un beau projet que de le faire en Lisaac lui-même, histoire de montrer la souplesse de celui-ci ;-)
Boulot énorme !
Falloir que j'étudie Apache, faire un module, gérer les get/post, faire une grosse API pour générer du html (parce que mettre du HTML dans le source signifie modifier le compilateur, donc il faut que ce soit du Lisaac classique qui génère du HTML), faire un binding pour gérer une BDD (pas encore fait).
C'est une bonne idée parce que le serveur surement très bien la charge, mais j'ai peur du boulot que ça implique...
S'il y a des volontaires...
A propos des espaces de nom, c'est l'un des gros defaut d'Eiffel de ne pas les supporter. Il s'agit de tout simplement hierarchiser les classes sous une arborescence ressemblant a un systeme de fichier. Si on est intelligent, on les range après physiquement dans des sous dossiers de même nom ;-)
Cela permet de ne pas avoir toutes les classes aux mêmes niveaux mais de les répartir en domaine. Par exemple, en perl, les modules (classes) sous Net:: concerne le reseau avec Net::Telnet par exemple. Idem, sous CGI:: il y a tous les modules concernant la gestion CGI du web et ainsi de suite.
C'est une idée séduisante, mais j'entend d'ici la réponse de Benoit.
"Oui, mais comme le compilateur va chercher tout seul les objets... Je vois pas l'utilité"
Faut savoir qu'en Lisaac, tu n'as pas de import à faire comme en perl ou en Java.
Tu as un fichier path.li qui se trouve dans le répertoire $LISAAC, et celui-ci contient divers infos comme la liste des répertoire contenant les objets de la lib.
Après le compilateur se débrouille : si tu fait - a : OBJET_TOTO;
il ira chercher objet_toto.li tout seul.
Cela dit, c'est une idée intéressante pour une question de rangement et sur le CLAN, il faudra le ranger comme cela.
Réflexion : je suis sur qu'il y a quelque chose avec faire avec cet espace de nom. Par exemple, les attributs privés seraient accessible dans le même espace de nom... Ou on pourrait avoir des classes privé accessible que depuis le même espace de nom. Ce dernier exemple m'est déjà arrivé. Je voulais avoir une classe accessible depuis plusieurs autres classes de mon projet mais je ne voulais pas rendre son API public. A l'heure actuelle, ce n'est pas possible.
Je suis persuadé qu'il y a une place entre public et private dans les structures des langages, mais pas le protected du C++. Par exemple, le mot 'friend' rendrait les choses accessible à l'espace de nom. L'espace de nom n'ayant rien a voir avec l'arbre des classes. L'espace de nom n'est qu'un rangement que l'homme décide pour son classement.
Il faut savoir (voir manuel utiisateur sur le site) qu'en Lisaac tu as la possibilité d'aller un peu plus loin que le "protected" de c++.
Le protected correspond à toutes les méthodes défini dans la Section SELF
Evidemment c'est généralisable :
Tu peux si tu le désir définir du code dans une Section MACHIN, TRUC
qui implique que ton code écrit dans cette section sera accessible uniquement aux prototypes MACHIN, TRUC ainsi qu'à leur descendants.
Evidement avec un espace de nom, on peut imaginer d'aller plus loin, parce qu'espace de nom est différent de l'héritage. NET.HTTP ne signifie pas que HTTP hérite de NET (dans la pratique, il y a des chances, mais il faudrait que ce ne soit pas obligatoire).
On pourrait donc imaginer de jouer avec cette histoire de section pour définir l'accessibilité des méthodes.
Mais ça risque de faire doublon.
Qu'en penses-tu ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
Boulot énorme !
Falloir que j'étudie Apache, faire un module, gérer les get/post, faire une grosse API pour générer du html (parce que mettre du HTML dans le source signifie modifier le compilateur, donc il faut que ce soit du Lisaac classique qui génère du HTML), faire un binding pour gérer une BDD (pas encore fait).
C'est une bonne idée parce que le serveur surement très bien la charge, mais j'ai peur du boulot que ça implique...
S'il y a des volontaires...
A propos des espaces de nom, c'est l'un des gros defaut d'Eiffel de ne pas les supporter. Il s'agit de tout simplement hierarchiser les classes sous une arborescence ressemblant a un systeme de fichier. Si on est intelligent, on les range après physiquement dans des sous dossiers de même nom ;-)
Cela permet de ne pas avoir toutes les classes aux mêmes niveaux mais de les répartir en domaine. Par exemple, en perl, les modules (classes) sous Net:: concerne le reseau avec Net::Telnet par exemple. Idem, sous CGI:: il y a tous les modules concernant la gestion CGI du web et ainsi de suite.
C'est une idée séduisante, mais j'entend d'ici la réponse de Benoit.
"Oui, mais comme le compilateur va chercher tout seul les objets... Je vois pas l'utilité"
Faut savoir qu'en Lisaac, tu n'as pas de import à faire comme en perl ou en Java.
Tu as un fichier path.li qui se trouve dans le répertoire $LISAAC, et celui-ci contient divers infos comme la liste des répertoire contenant les objets de la lib.
Après le compilateur se débrouille : si tu fait - a : OBJET_TOTO;
il ira chercher objet_toto.li tout seul.
Cela dit, c'est une idée intéressante pour une question de rangement et sur le CLAN, il faudra le ranger comme cela.
Réflexion : je suis sur qu'il y a quelque chose avec faire avec cet espace de nom. Par exemple, les attributs privés seraient accessible dans le même espace de nom... Ou on pourrait avoir des classes privé accessible que depuis le même espace de nom. Ce dernier exemple m'est déjà arrivé. Je voulais avoir une classe accessible depuis plusieurs autres classes de mon projet mais je ne voulais pas rendre son API public. A l'heure actuelle, ce n'est pas possible.
Je suis persuadé qu'il y a une place entre public et private dans les structures des langages, mais pas le protected du C++. Par exemple, le mot 'friend' rendrait les choses accessible à l'espace de nom. L'espace de nom n'ayant rien a voir avec l'arbre des classes. L'espace de nom n'est qu'un rangement que l'homme décide pour son classement.
Il faut savoir (voir manuel utiisateur sur le site) qu'en Lisaac tu as la possibilité d'aller un peu plus loin que le "protected" de c++.
Le protected correspond à toutes les méthodes défini dans la
Section SELF
Evidemment c'est généralisable :
Tu peux si tu le désir définir du code dans une
Section MACHIN, TRUC
qui implique que ton code écrit dans cette section sera accessible uniquement aux prototypes MACHIN, TRUC ainsi qu'à leur descendants.
Evidement avec un espace de nom, on peut imaginer d'aller plus loin, parce qu'espace de nom est différent de l'héritage.
NET.HTTP ne signifie pas que HTTP hérite de NET (dans la pratique, il y a des chances, mais il faudrait que ce ne soit pas obligatoire).
On pourrait donc imaginer de jouer avec cette histoire de section pour définir l'accessibilité des méthodes.
Mais ça risque de faire doublon.
Qu'en penses-tu ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker