Nous, pauvres programmeurs, devont le faire à la main, avec des boucles.
Le comble est qu'il existe des langages très bien conçus pour manipuler des donnés au sein d'arborescences de donnés. OQL en est un exemple.
OQL est une extention de SQL pour les SGBDO.
On pourrait utiliser d'autres dialectes, l'essentiel étant d'avoir un langage simple et intuitif, OQL me parait un bon candidat.
J'ai personnellement beaucoup de facilités avec des langages type SQL, et beaucoup de difficultés avec la manipulation d'arbre de donnés avec des boucles. J'adore jouer avec le premier et déteste me farcir le second exercice.
De plus je trouve totalement stupide que l'on continue en 2007 à encore faire à la main quelque chose qui pourrait être automatisé. On nous parlent sans cesse de diminuer les coûts, mais on perd des heures (et beaucoup d'argent) sur des problèmes de ce genre.
Cela éviterait de plus de nombreux bugs, qui coutent eux aussi très cher.
Microsoft l'a bien compris, en proposant un langage SQL interne dans C# (LINQ)
Bref, c'est pour cela que je vous propose le projet "OQLtoLang", dont l'objectif est de générer le code de toute sorte de requête OQL pour différent langage.
On pourra ainsi générer du java, Perl, Python, C++, etc...
Un système de plugin permettra d'adapter le code de sortie aux spécificités de chaque langage.
En effet, selon le genre de chose que l'on code, on a pas obligatoirement un framework genre Hibernate ou autre sous la main. De plus, il est souvent fastidieux de coder un interpréteur dans le langage que l'on utilise et utiliser ce genre de manière "tordu", au yeux de certains chefs de projet pas très ouvert, peu provoquer des problèmes. Un interpréteur, qui plus est, intrinsèquement lent, implique aussi de veiller à ce qu'une couche de la librairie soit disponible, il impose de disposer de réflexivité dans le langage, etc...
Le but de ce projet est de générer un code lisible, compréhensible et reprenable par n'importe qui et correspondant à la requête.
En effet, dans une équipe, le niveau du code doit souvent être nivelé par le bas pour être compréhensible par tout le monde.
Une personne extérieur relisant le code doit croire qu'il s'agit d'une bête boucle écrit par un humain. Cela permettra à n'importe qui d'utiliser cet utilitaire avec n'importe quel langage, sans risquer aucun problème vis à vis de son équipe, de son supérieur, etc... Tout en gagnant énormément de temps.
J'ai commencé à écrire du code en Ocaml, non pas que c'est le langage que je maîtrise le plus, mais qu'il me parait le plus adapté, avec son type somme, pour le problème.
Faire ça sans type somme, ça serait l'horreur.
En voici une description didactique.
Je défini l'ensemble des type possible. C'est un système criticable parce qu'on pourrait avoir toutes sortes d'objet à récupérer, et du moment que l'on dispose d'une fonction d'égalité par référence et par structure sur 2 objets, cela suffirait amplement. On va faire sans pour le moment.
type types_possibles = Entier| Chaine| Date| Tablo_entier | Tablo_ch | Collection | Objet | Chaine_const | Entier_const | Date_const | Tablo_entier_const | Tablo_ch_const;;
Il faut ensuite pouvoir définir le chemin d'un objet (par exemple toto[4].proptab.elementAt(5).mumu ...), qui est ni plus ni moins qu'un chemin dans une arborescence
type chemin_obj = Feuille of string*types_possibles | Obj_seul of string | Obj of string*chemin_obj | Collect_seul of string|Collect of string* chemin_obj;;
On peut d'ors et déjà définir le select, liste d'items de l'objets à récupérer :
type axiom_select = string*types_possibles;;
type select = axiom_select list;;
Le from n'est pas compliqué à définir, c'est une liste de différents chemins.
type from = chemin_obj list;;
La représentation de la clause where est beaucoup plus complexe :
Dans une clause where, on trouve des comparaison (égalité, différence, supérieur, inférieur), bref des fonction binaire de type E,E -> bool , des tests ensemblistes d'appartenance ou non appartenance.
type axiom_where = Comparaison of comp_vars | Ensemblein of ens_in | Ensemblenotin of ens_not_in ;;
type where = axiom_where list;;
Une comparaison s'effectue entre deux objets. Il faudra ajouter plus tard la possibilité d'y mettre une sous requête à la place. je ne l'ai pas mis pour simplifier.
type operat = Egal | Diff | Sup | Sup_egal | Inf | Inf_egal;;
type comp_vars = { op : operat ; vc1: chemin_obj; vc2 : chemin_obj};;
Les test d'appartenance sont la comparaison entre deux élements : une requête, et un élement.
type ens_in = { ve1 : chemin_obj; r : requete};;
type ens_not_in = { vf1 : chemin_obj; r : requete};;
une requête est donc la synthèse de tout cela :
type requete = { sel : select ; from : from ; where : where };;
Il nous faut maintenant modéliser le code :
type code = Foreach of chemin_obj*code | Test of chemin_obj*chemin_obj*code | Ajout of chemin_obj;;
permet de modéliser
res : liste d'objet CNN // type donné par select
pour chaque Figure.ListeDeCNN
i : entier
pour chaque Figure.ListeDeCNN[i].Property
j : entier
si Figure.ListeDeCNN[i].Property[j].NomValeur == "SEE_CNN" alors
res.ajoute(Figure.ListeDeCNN[i]) // type de select
fin si
fin pour
fin pour
avec
Foreach(
Obj("Figure",Collect_seul("ListeDeCSN")),
Foreach(
Obj("Figure",Collect("ListeDeCNN",Obj("Property",Feuille("NomValeur",Chaine_const)))),
Test(Collect("ListeDeCNN",Obj("Property",Feuille("NomValeur",Chaine_const))),
Feuille("SEE_CNN",Chaine_const),
Ajout(Obj("Figure",Collect_seul("ListeDeCNN")))));;
Ce code correspond à la requête :
select CNN.Object
from
Figure.ListeDeCNN.Property
where
Figure.ListeDeCNN.Property.NomValeur = "SEE_CNN"
transformé selon la structure de donné en :
let req = { sel = ("CNN.Object",Objet) ;
from = [Obj("Figure",Collect("ListeDeCNN",Obj_seul("Property")))];
where = [Comparaison({
op = Egal ;
vc1 = Obj("Figure",Collect("ListeDeCNN",Obj("Property",Feuille("NomValeur",Chaine_const)))) ;
vc2 =Feuille("SEE_CNN",Chaine_const)})] };;
Je ne me suis pas lancé dans le code de la fonction qui va transformer la requête en code, en partie parce que je ne maîtrise pas assez bien ocaml et surtout par manque de temps.
je cherche des personnes intéressées par la création de ce projet. Ocaml n'est pas imposé, bien qu'il me semble le plus adapté et le plus clair pour ce genre de chose avec son type somme et son filtrage de type.
Si certains sont intéressés, nous pouvons créer un projet sur GNA ou un autre hébergement de ce style.
Partant ?
# Gestion d'arbres par représentation intervallaire
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
As-tu déjà jeté un coup d'oeil à la gestion d'arbres par représentation intervallaire ?
http://sql.developpez.com/arborescence/
En clair : plus besoin de faire des boucles dans tous les sens pour récupérer une arborescence. Une seule requête suffit. Seul bémol : la modification de l'arbre (insertion, suppression de noeud) est un poil plus compliqué qu'un simple insert ou delete, mais je trouve que c'est plus supportable que de récupérer une arborescence.
Il me semble aussi qu'il existe une extension pour postgresql qui permet de gérer des arborescences.
[^] # Re: Gestion d'arbres par représentation intervallaire
Posté par Ontologia (site web personnel) . Évalué à 3.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Gestion d'arbres par représentation intervallaire
Posté par Guillaume Smet (site web personnel) . Évalué à 2.
Oui, il s'agit de ltree ( http://www.sai.msu.su/~megera/postgres/gist/ltree/ ). Comme beaucoup d'extensions PostgreSQL, il s'agit d'un type particulier et d'un ensemble d'opérateurs/fonctions pour ce type (et ça utilise le framework GiST pour les index).
Le principe est simplissime. L'arbre est créée sous la forme Racine, Racine.Noeud1, Racine.Noeud1.Noeud2. Chaque noeud a donc un libellé propre et un chemin depuis la racine. Ensuite des opérateurs permettent d'obtenir les fils, les parents...
Pour l'utiliser dans un projet, ça marche très très bien. La seule contrainte est qu'il faut mettre à jour tous les fils quand on déplace un noeud car chaque noeud a le chemin complet de l'arborescence (cette manipulation est triviale mais peut causer la mise à jour d'un grand nombre de noeuds).
Les opérateurs fournis permettent de manipuler l'arbre de manière triviale et très rapide (en posant les index qui vont mieux).
Et pour finir, il est très facile de se rendre compte de la tête de l'arbre et de détecter un problème en regardant les lignes de la table, ce qui est loin d'être toujours le cas avec les autres méthodes.
Le problème, c'est que ce n'est pas portable du tout donc à réserver à des projets pour lesquels la portabilité des requêtes n'est pas une contrainte.
# Tom
Posté par Thomas Douillard . Évalué à 2.
Langage qu'on peut utiliser avec du java et du C++ je crois, c'est bien mieux que ces infames visiteurs très lourds à manipuler.
[1] http://tom.loria.fr/
[2] http://linuxfr.org/2007/07/13/22730.html
[^] # Re: Tom
Posté par Ontologia (site web personnel) . Évalué à 2.
Premièrement, c'est beaucoup trop surdimensionné par rapport au besoin que je définis.
Deuxièmement c'est encore un truc d'universitaire de plus, qui comme de nombreux projet universitaires est conceptuellement géniak, mais totalement imbitable.
Si mon chef me voyait utiliser ce truc, il me truciderait sur place.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Heu...
Posté par Antoine . Évalué à 2.
Ceci dit, tu peux regarder du côté des "list comprehensions" qui existent comme certains langages comme Python.
Par exemple ton code :
res : liste d'objet CNN // type donné par select
pour chaque Figure.ListeDeCNN
i : entier
pour chaque Figure.ListeDeCNN[i].Property
j : entier
si Figure.ListeDeCNN[i].Property[j].NomValeur == "SEE_CNN" alors
res.ajoute(Figure.ListeDeCNN[i]) // type de select
fin si
fin pour
fin pour
pourrait s'écrire à peu près (en Python) :
[CNN
for CNN in Figure.ListeDeCNN
for prop in CNN.Property
if prop.NomValeur == "SEE_CNN"]
(j'ai ajouté des retours chariots pour rendre l'enchaînement plus lisible mais le tout est une expression unique qui peut s'écrire sur une seule ligne)
[^] # Re: Heu...
Posté par Ontologia (site web personnel) . Évalué à 2.
Imagine que tu travaille dans une SSII, sur un projet quelconque en Java, C++, etc...
Tu es dans une entreprise donc, tu travailles sur l'amélioration d'un logiciel qui possède déjà des milliers de lignes de code depuis des années.
Le language t'es imposé, l'éditeur texte t'es imposé, etc...
On te donne un cahier des charges dans lequel on te demande de sortir un reporting sur des classes interne au projet. ce reporting étant effectué au sein du logiciel, pendant qu'il tourne sur les objets en mémoire.
Tu n'as pas hibernate ou qq chose du genre, on te donne un liste stricte de librairie à utiliser, le reste étant interdit.
Il te faut jongler avec plein de donnés pour refaire, à la main des manipulation qui prendrai 10 fois moins de temps en SQL (je n'exagère pas).
Si tu as la "chance" d'utiliser C# et d'avoir le droit d'utiliser LINQ (oui parce qu'on peut t'interdir de coder de tel façon (pas de fonction lambda, etc...)) , le problème n'a pas lieu, mais si tu utilise Java, c++, ou autre chosen t'es obligé de tout faire à la main.
Mon objectif est donc de disposer d'un espèce de script qui prend en entrée une requête OQL, et te rend du code que tu pourras mettre dans ton source, comme si tu l'avais écrit à la main.
Comme ça, tu n'utilise pas de librairie interdite, tu n'as pas écrit de parser SQL qui ferai hurler ton chef de projet, etc... etc...
Python est un beau langage, mais dans une SSII, on te parle plus souvent de J2EE, etc...
Mais merci de me faire découvrir qu'on peut aller aussi loin avec ce langage :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Heu...
Posté par romain . Évalué à 7.
[^] # Re: Heu...
Posté par Guillaume Knispel . Évalué à 4.
Quoi qu'il en soit, dans un tel contexte, mieux vaut effectivement compiler du code à partir de quelque chose ayant une expressivité correcte plutôt que de le pisser bêtement. Pourquoi perdre son temps à implémenter machinalement des spécifications au lieu de rendre les spécifications exécutables ? :) (quitte à le faire en douce si jamais le chef de projet voit ça comme une menace envers son emploi :P )
Ceci étant "l'éditeur de texte t'es imposé" me laisse sans voix. Ils fouettent les employés bruyants aussi ?
[^] # Re: Heu...
Posté par ham . Évalué à 4.
- un certain nombre d'outils et de procédure sont déja intégrée à l'outils (indentation, template pour les commentaires, ....etc)
- passer deux semaines pour configurer correctement vim/emacs/eclipse pour s'interfacer avec les outils de la boite (proprio, ...etc) ca peut etre mal vu
- éviter le fait que l'éditeur préféré ne marche que sous windows alors que tout doit se faire sour unix/linux/etc (gestion de versions et de collaboration qui est sur le serveur de dev, on doit éditer les fichiers sur cette machine, par exemple)
- des gens ont passés 5 ans a customiser vim pour que ce soit configuré exactement pour le projet, le stagiaire/consultant ne peut pas faire pareil pour emacs dans un temps raisonable.
Ensuite quand l'éditeur est imposé c'est pas ed non plus, donc ca reste utilisable, voir même configurable (mettre les raccourcis connus par exemple, on peut meme utiliser les raccourcis emacs sous visual studio...)
D'aprés la description je suppose qu'il y a des conventions de codage et qu'elles doivent ètre respectées (sisi ca peut être utile). Autant dans les projets perso/école le code est peu repris/petit, autant sur des gros projets, le code peut vivre longtemps (Cf l'article sur les mainframes, le code a 20 ans) donc c'est vachement plus facile à maintenir si tout le code est écris de manière consistante, même si ca équivaut niveler par le bas.
Ensuite si tu arrive a configurer ton éditeur de texte préféré pendant tes pauses pour que ce soit intégrée a l'environement et au régles, ca risque de passer inaperçus et tout le monde va s'en foutre.
Dans mon projet on a des régles a respecter (édition sur le serveurs de dev, convention d'écriture de code) et des éditeurs conseillé, ensuite les gens utilise l'outils qu'ils veulent.
Résultat : règle plus ou moins suivis parceque les gens sont des moules.
Moralité : Si on veut des règles bien respecté, plus le travail est encadré (avec un éditeur imposé par exemple) moins la flemmardise/les mauvaise habitubes auront d'impact.
[^] # Re: Heu...
Posté par Mouns (site web personnel) . Évalué à 4.
je sors -> []
[^] # Re: Heu...
Posté par wismerhill . Évalué à 1.
http://iced-tea.org/wiki/Main_Page
[^] # Re: Heu...
Posté par Brice Carpentier . Évalué à 2.
La chose la plus stupide que j'ai jamais connue ...
[^] # Re: Heu...
Posté par ham . Évalué à 2.
Mon laptop n'a pas de backup particulier , et je vois pas la différence entre utliser un éditeur/IDE X ou Y en local ou sur une machine distante, a part que sur la machine distante ca peut etre gérée de maniere centrale , le serveur est généralement mieux fournis en processeur et en en RAM.
Ensuite si la machine est sous dimensioné, c'est aussi stupide en local
et en ayant un serveur central.
[^] # Re: Heu...
Posté par Guillaume Knispel . Évalué à 2.
Quand à prendre comme argument la puissance de la machine quand on parle de ce servir d'un éditeur (ou d'un IDE dont la fonction principale est tout de même ... éditeur)... ça illustre tout à fait la qualité déplorable de certains logiciels en terme de consommation idiote de ressources :P
Enfin bon quand je vois OOO, Firefox, Gnome et Eclipse, effectivement je ne m'étonne plus de rien quand à la tolérance des utilisateurs pour les logiciels bloatwares qui rament. (l'ironie est que je poste ce commentaire depuis Firefox :p )
[^] # Re: Heu...
Posté par ham . Évalué à 1.
La on peut dire qu'on peut faire des branhc instable par dev, ...etc
mais pour que ca marche il faut que les dev soient disipliné , aient du bon sens et commit régulierement pour que ca marche, Ca marche peut etre tout le temps chez les bisounours, mais dans la vrai vie c'est pas fréquent.
Ensuite la puissance de la machine c'est plus pour compiler les 150 mégas de code source (et encore c'est du C, ca compile vite) que pour faire tourner l'IDE, et aussi réutilisér les objects déja compilé.
Pareceque passer une heure pour tout recompiler, c'est mieux si c'est mutualisé pour tout les dev.
Alors sur des truc pas trop gros, avec des systéme bien séparé c'est faisable, mais c'est pas toujours le cas.
[^] # Re: Heu...
Posté par Brice Carpentier . Évalué à 1.
Pour les 150 Mo de code source, déjà si t'es obligé de tout recompiler à chaque fois c'est qu'il y a un beau problème d'architecture logicielle.
En gros je pense que tu résumes très bien la chose :
En gros, il faut que les devs fassent bien leur boulot ... je pense que tout le monde est d'accord là dessus.
[^] # Re: Heu...
Posté par TImaniac (site web personnel) . Évalué à 2.
Le langage en soit est peut être plus productif (et encore je suis pas sûr) mais ce qui compte pour une entreprise c'est pas le langage en soit : c'est la plateforme complète. Cad les libs en standard, leur cohérence, les outils de dev (aide au développeur mais également aide à l'architecte, au testeur, etc.), documentation ainsi que l'éco-système qui gravite autour : support éditeur, fournisseurs de services, compétences sous-traitant, etc.
Bref, si tu compares autre chose que les langages, tu verras que Python est loin d'être le plus productif dans bien des cas.
Pour le coup de l'éditeur de texte imposé, c'est plutôt "IDE imposé". Et ca fait toute la différence : un IDE demande des compétences, c'est autrement plus complexe qu'un simple éditeur : on peut y intégrer des modules supplémentaires spécifiques à l'entreprise (framework maison, etc.) par exemple, et puis souvent un projet a une certaine représentation (c'est pas une collection de .py) : y'a des fichiers sources, des ressources, des pages web, des interfaces graphiques, tout ca dans un format gérer différement par chaque IDE (il y a bien sûr des possibilités d'import/export, mais c'est utilisable que pour des migrations, pas en collaboration).
[^] # Re: Heu...
Posté par Brice Carpentier . Évalué à 1.
Alors qu'avec un langage expressif et une bonne méthodologie, c'est parfaitement inutile.
[^] # Re: Heu...
Posté par freeze . Évalué à 3.
ça apporte des fonctionnalités et des outils supplémentaires, mais c'est le cas pour les deux langage... vraiment, je ne comprends pas, vi + javac, j'y arrive tout aussi bien (avec Ant si le projet devient plus gros...)
J'ai marché dedans ? c'est tout ce que tu voulais ?
[^] # Re: Heu...
Posté par Gniarf . Évalué à 3.
assez bien, oui, il parlait des AUTRES langages, pas de C et C++ dont Java est tiré.
[^] # Re: Heu...
Posté par Guillaume Knispel . Évalué à 3.
Extrêmement performant pour tout ce qui est prévu.
Extrêmement lourd et contre productif pour tout ce qui de rentre pas dans le moule de l'IDE et du langage, et... c'est justement ce qu'explique ce journal!
Forcement quand on est expert dans un domaine, ça fait mal de voir qu'il y a un manière de le faire 25x plus vite en utilisant d'autres outils. Alors on se console comme on peut en se disant que sur ce point particulier on perd, mais que dans la majorité des autres cas on gagne.
A voir l'histoire des projets informatiques remplis de succès rapides dus aux gens qui utilisent un outil en rupture et bien adapté à un problème précis donné, j'ai énormément de mal à croire en l'outil ultime qui fait tout d'une manière en moyenne optimale. Et j'ai encore plus de mal à croire que cet outil est à tout instant le truc à la mode du moment (ou l'avant dernier truc à la mode).
Un outil n'est jamais adapté simultanément à tout. Les outils qui tentent de le devenir sont plus typiquement médiocre en tout que bon en tout... Il en va de même pour les compétences: si on se limite à des "experts langage XYZ" comment réagir quand les besoins fonctionnels vont changer vers un domaine encore inconnu pour eux? Le langage ne devrait être qu'un détail. Hors il est des secteurs où il est devenu un critère principal de détermination de compétence. C'est aussi ça que je critique.
Vu sous cet angle enfermer tout un projet dans une IDE et dans un langage, et ce surtout quand il est de grande envergure, me laisse sans voix.
Un projet de grande envergure ne peut pas se permettre de fixer des choix technologiques arbitraires restreints à ce point pour cause d'IDE manquant d'ouverture sur le monde surtout quand on considère la volatilité du marché informatique. On est dans un contexte ou quelque chose qui ne s'integre bien qu'avec les trucs du même type va forcement poser des problème à un point donné.
Java est peut être très adapté pour certains problèmes mais croire qu'il peut tout faire tout seul ou à grand coup d'outils magiques est une erreur monumentale. C'est tout aussi grave que de dire qu'on veut déployer une archi énorme entière sous Linux juste pcq'on aime Linux, sans même prendre la peine d'étudier les besoins multiples et divers de l'application considérée.
Bref tout ça pour dire d'un langage n'est qu'un outil et qu'une IDE aussi, et que s'enfermer dans un seul outil pour un gros projet n'a pas vraiment de sens en terme de productivité. Un projet bien géré saura être souple et garder une archi cohérente tout en s'autorisant d'utiliser les outils potentiellement différents les mieux adaptés aux fonctions à intégrer sous réserve de couplage suffisamment souple pour permettre ça.
Et sur un gros projet, un couplage technique tellement rigide qu'il ne permettrait ce genre de souplesse nul part est typiquement le signe d'une mauvaise archi et/ou de mauvaise directions techniques prises sans que le besoin ait été correctement qualifié.
[^] # Re: Heu...
Posté par Ontologia (site web personnel) . Évalué à 2.
On choisi Java, parce qu'il y a beaucoup de lib, comme Timaniac l'expliquait, parce que le client le demande, souvent, et surtout parce qu'on est sur que des compétences Java, on en trouvera très facilement à pas cher sur le marché....
Personnellement, je pense que Java est tout sauf un langage intéressant, il a 30 ans de retard, il est verbeux, la lib standard est nulle, etc...
Mais tout le monde le maitrise et tout est écrit avec.
Les décideurs ont pas le niveau pour choisir les bonnes technologies, il sont de trop bonnes cibles marketing.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Heu...
Posté par Antoine . Évalué à 4.
Qu'appelles-tu un "reporting" ? Je ne parle pas le SSII-speak :)
# LINQ
Posté par pasBill pasGates . Évalué à 2.
Ca serait peut-etre plus simple de voir comment ils font eux (si j'ai bien compris ton idee).
[^] # Re: LINQ
Posté par Ontologia (site web personnel) . Évalué à 2.
LINQ (j'en parle dans le journal) est intégré dans la grammaire de C#.
Je cherche à faire un utilitaire qui me permette de me traduire une requête SQL en code de n'importe langage.
Le but étant que la personne qui passe derrière toi, ne voit que des boucles classiques, claires, bien écrites et ne se rendent pas compte qu'il s'agit du code généré.
Imagine donc, je donne à mon utilitaire :
select CNN.Object
from
Figure.ListeDeCNN.Property
where
Figure.ListeDeCNN.Property.NomValeur = "SEE_CNN"
Il me renvoi
res : liste d'objet CNN // type donné par select
pour chaque Figure.ListeDeCNN
i : entier
pour chaque Figure.ListeDeCNN[i].Property
j : entier
si Figure.ListeDeCNN[i].Property[j].NomValeur == "SEE_CNN" alors
res.ajoute(Figure.ListeDeCNN[i]) // type de select
fin si
fin pour
fin pour
là c'est de l'algorithme mais imagine qu'il puisse me le rendre en C, C++, Java, Eiffel, etc...
Le langage que je veux...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: LINQ
Posté par TImaniac (site web personnel) . Évalué à 1.
Tu peux t'amuser à compiler du code C# 3 puis à le décompiler pour obtenir les sources : c'est du C# 2.
LINQ n'est donc qu'un ensemble de bibliothèques pour manipuler des arbres d'expressions, les sources de données sous-jacentes sont complètement décorélées : objet, SQL, XML, NHibernate, Amazon Web-services, code Java, ce que tu veux.
Fonctionnement de LINQ : http://aabs.wordpress.com/2006/12/15/how-linq-works-%E2%80%9(...)
[^] # Re: LINQ
Posté par ham . Évalué à 2.
Je pense qu'une manière de faire est de partir de l'existant pour la géneration de representation intermédiaire et de transformer l'arbre.
Ensuite vu que ta contrainte c'est de pouvoi faire du code pas trop évolué, ca doit pas ètre trop dure d'avoir une grosse partie du Backend génerique (pour les while, ..etc) et ensuite avoir des transformation spécifique pour les vérification.
Le liens donné ailleurs sur LINQ permet d'avoir un début pour savoir les technos utilisable, entre autre j'ai trouvé :
http://en.wikipedia.org/wiki/Abstract_syntax_tree
http://www.hibernate.org/ -> integre un langage de query avancé et est open source : possibilité de récupérer le frontend pour générer l'AST, voir plus .
Ensuite la partie moins simple et de pouvoir avoir un système de backend flexible (adaptable aux différentes librairie utilisé.
l'OMG travaille sur un framework pour le refactoring : http://adm.omg.org , RFP#7 , mais c'est pas encore sortie.
http://www.polytech.unice.fr/~blay/ENSEIGNEMENT/LOG8/MetaMod(...)
Sinon on peut utiliser un système a base de XML pour utiliser les outils de transformation d'arbre existant (XSLT, XLS/FO ).
[^] # Re: LINQ
Posté par ham . Évalué à 3.
un parseur OQL existe déja en java : http://www.makumba.org/hacking/javadoc/org/makumba/db/sql/oq(...)
Ils transforment le OQL en SQL,
de plus il y a un générateur de code basé sur SQL : http://www.uesqlc.org/ , open source lui aussi.
IL permet de transformer du SQL en appel de code ODBC/JDBC en java/C++ avec des fichiers de configurations SGML permettant d'avoir une génération de code configurable.
Bref ca ressemble vachement a ce que tu veut faire, ou j'ai pas bien compris?
[^] # Re: LINQ
Posté par Pierre Tramonson . Évalué à 1.
cf http://www.techheadbrothers.com/Articles.aspx?Id=2f886443-71(...)
http://www.dotnetguru.org/articles/articlets/linq/Linq.htm
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.