Dans le systeme présenté ci-dessus, le serveur chiffre avec la clef publique de l'utilisateur. Cependant, rien ne l'empêche a ce moment la de mettre une clef unique par stéganographie ;-) Du coup, retrouver la source devient beaucoup plus facile, chaque film diffusé étant unique.
C'est vrai que c'est pratique mais avec du recul, c'est pratique pendant combien de temps ? Combien coute de faire des "restart" ? Au bilan, tu acceptes de diminuer ta sécurité pour un problème annexe, qui ne peux pas être, a ma connaissance, dé-activé.
Sinon, nous sommes d'accord, gconf en fait bien plus que ce pour quoi il est appeller : les fichiers de configuration.
Le propre d'UNIX est la séparation des taches. A cause de ce gconf qui en fait trop, gimp n'utilise pas gconf.
Moi, ca me gonfle qu'ekiga utilise gconf pour ces parametres (/A priori/, il ne partage rien avec les autres). Ca m'oblige a avoir un daemon gconfd qui tourne.
Idem, si je fais mon propre programme. Je ne veux pas forcement avoir un daemon gconfd qui soit associé a mon programme. D'ailleurs, pour mes fichiers de configuration, j'utilise le format YAML qui est très simple et répond parfaitement au cahier des charges.
Bref, j'aime beaucoup de programmes fait avec les librairies gtk et gnome mais je n'ai pas envie d'avoir toute l'artillerie de gnome derrière pour un simple problème de configuration de mes applications (remarque, c'est pareil avec les application kde). Je ne veux pas être enfermer a choisir soit les applications gnome ou les applications kde. Je veux pouvoir piocher et utiliser les applications qui me plaisent. Bref, la base gnome a un peu trop tendance a t'enfermer dans son environnement.
Je reprends, cvs gère les fichiers binaires, il faut mettre l'option -kb. Ce que je ne me souviens plus, c'est si il garde chaque version, j'avais le souvenir qu'il ne gardait que la dernière.
subversion gère aussi parfaitement les méta-données. Pour les fichiers binaires, il les détecte automatiquement et n'en conserve que les xdelta de différence.
Bref, subversion est très robuste, simple.
Si tu veux un mode local, tu peux utiliser la surcouche décentralisé svk qui marche aussi très bien.
Les autres gestionnaires de versions, je ne les connais pas trop mais j'ai souvent eu l'impression qu'ils sont plus orientés code source que subversion. Par exemple, les gestionaires basé sur la notion de patch sont super bien pour améliorer le développement de code source, ca oblige a dissocier les modfications que l'on apporte en fonction d'objectif clair. L'idée derrière est de pouvoir appliquer les patch dans un autre ordre, et c'est généralement possible.
Dans le cas de fichier binaire, on est obligé de suivre l'ordre des "commit". La notion de patch a donc moins d'intérêt il me semble.
A propose de gconf, il y a des paramètres dans gconf qui sont pris en charge instantanément. Ce n'est pas le cas des fichiers de configuration. Si tu modifie la configuration d'Apache par exemple, il faut lui envoyer le signal HUP pour qu'il recharge a chaud sa configuration. C'est le "restart" des anciens Window Manager basé sur le génial fvwm.
Dans un environnement gnome moderne, tu change un paramètre a un endroit et ca change partout instantanément. C'est beau mais je pense que c'est une mauvaise idée.
Le concept des UNIX est très simple. Des processus ayant des variables d'environnement qu'ils transmettre a leur fils, JAMAIS l'inverse ! Un fils a très peu de pouvoir sur un père (et réciproquement). Il faut mettre en place des outils de plus haut niveau pour faire communiquer les processus (segment de mémoire partagé...)
Pour en revenir a gconf, s'il ne remplacais que les fichiers de configuration, pourquoi tourne-t-il en mode daemon. Ce serait une simple librairie dynamique que le programme chargerait au démarrage, que ce serait très bien.
Le problème est que gconf sers aussi a partager des données entre le programmes et ce n'est pas son rôle, en tout cas, je ne suis pas de cet avis. En plus, le nombre de paramètre a partager est très faible devant la quantité de paramètre spécifique à chaque programme. Bref, que ce rôle revienne à une autre application, pourquoi pas au D-BUS...
Je suis entouré de gens lambda et ils ne passent pas leur vie au bureau a changer les paramêtres de leur bureau !
Si ils utilisent un bureau a distance via xvnc, tu peux leur préparer un bureau bien configuré sous icewm (comme ca ils ne sont pas trop perdus) et t'as gagné un paquet de ressources.
Avoir un utilitaire graphique qui t'aide a paramétrer, pourquoi pas. Mais faut pas non plus en faire une condition éliminatoire.
Je suis d'accord que ma phrase sur gconf était un peu hors sujet. J'ai deja pas mal posté sur gconf et je maintiens que ce truc n'est pas bon et que c'est un equivalent des variables globales. D'ailleurs, il y a un daemon gcond qui tourne en permanence (meme que parfois, ce co. survie a une fermeture de sessions...).
Personnellement, ca fait longtemps que je suis passé sur une base debian. Sur cette base la, a ma connaissance, il n'y a pas 50 gestionnaire de paquet, quel que soit la distribution. Par ailleurs, il m'arrive da faire mes propres .deb car c'est plus facile à déployer ensuite sur un gros parc de machine.
Donc, je ne vois pas le problème que tu invoques, surtout que j'avais parlé de faire une API commune. Après, que chaque distribution fasse ses propres paquetages avec ses numéros de version, c'est autre chose et cela n'a rien a voir avec le gestionaire lui même.
Malheureusement, il n'y avait aucune blague dans mon post.
Dans la fonction publique, tu es soumis à la règle des marchés, tu n'as donc pas le choix de ce que tu achètes. DELL a perdus le marché des serveurs au CNRS et c'est NEC qui l'a. Cela veut dire que si tu achètes via le CNRS, tu te retrouves avec une machine NEC, ou alors, faut justifier que NEC ne propose pas ce que tu souhaites.
Cependant, NEC a l'air assez ouvert même si leur matériel est surtout validé pour RedHat et Novell (et Windows). Tous les moyens sont donc bons pour qu'il s'ouvre encore plus et valide un plus grand nombre de distribution, notament une base différente que la RedHat.
Il en ai de même avec pas mal de logiciels propriétaires : matlab, comsol (ex femlab)... Si tu ne les installes pas sous RedHat ou Novell, tu perds le support, et ceci même si ca marche très bien.
Quelqu'un pourra m'expliquer cette folie de se faire chacun ses commandes pour installer les rpm ? urpmi, apt2rpm, yum... Pourquoi ils ne travaillent pas ensemble ?
C'est si dur que cela que de décrire un cahier des charges et une API et de partager ensuite le développement ?
sauf que debian ne les sors pas officiellement ! Et puis,les debian se mettent a jour sans CD d'une version a une autre... Bref, ca n'a rien a voir.
On m'a refilé un serveur sous fedora, j'attend la panne matériel pour le reformater sous debian. Rien à voir, mais si il y a du monde dans la salle, vous pouvez comme moi titiller NEC a propos de debian qui a le marché serveur au CNRS. A chaque fois que je les ais au bout du fils, je leur en parle.
Personnellement, j'utilise pwm car je ne veux pas de barre de titre ayant la largeur de la fenêtre... Cependant, je ne bidouille pas mon environnement TOUS les jours ! J'ai personnellement un script qui a tous les paramêtres qui vont bien, je le lance au démarrage et c'est bon. Les rares fois ou je veux modifier un paramêtre, je "restart" mon gestionaire de fenêtre.
Désolé mais le tout graphique avec du gconf en variable globale... c'est bien un peu mais des choses simples, c'est bien aussi.
J'ai un copain au Canada (Montréal), son fournisseur lui file une adresse IPv6, rien en IPv4. Dommage, on a jamais reussi a communiquer correctement, il y a toujours un canal qui foire.
Bref, IPv6 est déjà là.
Sinon, j'ai jamais fait de la programmation réseau mais j'avais compris qu'avec le systeme de couche, on ne se préocuppait pas trop de la couche en dessous dans tcp/ip. Il n'y a pas d'instruction pour ouvrir une socket reseau vers un nom dns et hop, ca se débrouille ?
> Comment faire pour sélectionner son éditeur de texte dans Gnome?
Je viens de faire l'essai ce soir, c'est vrai que Nautilus ne tiens pas compte de la variable d'environnement EDITOR. Ca sers a quoi ces bonnes vielles variables ?
> Enfin voila, ca ne vous intéresse peut être pas mais c'est un peu ce
> que j'attend d'un éditeur de texte ...
J'ai aussi besoin de faire des selections carré, c'est à dire pouvoir sélectionner un bloc rectangulaire positionné n'importe ou et pouvoir le déplacer graphiquement. nedit fait ca super bien ;-)
Sinon, c'est vrai que le copier coller qui ne suis pas la tradition unix du bouton du milieu est fatal pour mon gedit 2.8.3. Bref, gedit, ca va pour lire un readme mais guère plus.
> Et je réponds à nouveau que si tu cherches la récursivité, tu utilises
> des noeuds (donc des balises). D'un point de vue temps de
> définition, c'est à peu près équivalent (avec une DTD).
C'est un peu un probleme. Surtout que les noeuds sont fait pour etre un conteneur et non expliciter le noeud lui-même. Par exemple, dans une interface graphique, je peux assigner des signaux aux éléments graphiques sous forme d'attribut et mettre d'autres éléments graphiques dedans. Si je passe mes atributs sous forme de noeud, je peux avoir des clash avec les noeuds qui sont déjà la.
Il est vrai que si les attributs deviennent des arbres a part entière, la ligne de démarcation attribut/noeud sera moins claire, ce sera au schema de la préciser. Mais au moins on aura une double structure symétrique ayant une API propre laissant le développeur s'exprimer.
> Euh non. :-)
T'as raison, j'avais mal saisie la dynamique de la phrase.
Pour la suite, je suis d'accord que le développement du XML texte a dynamiser, popularisé, révolutionné (...) le développpement de librairies de recherche dans les arbres. et je trouve ca TRES BIEN. C'est le XML texte que je n'aime pas.
> XML, dans sa forme « écrite » n'a rien à voir avec ce qu'est XML
> fondamentalement.
Tu vois, on est d'accord ;-) Sauf que moi, le XML fondamentalement, je l'appelle arbre. Même que parfois, on est limité et on a la structure de graphe qui est pas mal et ce serait bien si elle profitait de la même énergie que les arbres.
> on s'en fiche un peu.
Malheureusement non. La mode Tomcat est au fichier de conf imbittable. Tu prends les fichiers de conf des modules Perl sur le CPAN, du beau YAML, c'est que du bonheur.
> NB : en TeX/LaTeX, tu as aussi des attributs, qui ne sont pas
> récursifs non plus, et qui - surprise ! - sont non ordonnés :
Attention, TeX est reprogrammable ! Si LaTeX avait eu la même énergie mise dessus que le XML, on aurait une API tip-top. Je sais qu'il y a des problèmes avec TeX mais regardes le nombre de personnes qui sont dessus. C'est quand même impressionant pour ce résultat.
> Si tu continues comme ça, tu pourrais dire qu'à part XSL/T, les
> langages de transformation de XML ne ressemblent pas trop à du
> XML.
Justement, je continue. C'est pour cela que je parle de fatras. Au moins, en TeX, tu programmes en TeX ;-)
> Et après ? XML est fait pour être lu par des machines.
Encore une fois, je suis d'accord. Mais autant prendre alors un format binaire. C'est bien plus performant. Si mes souvenirs sont bon, le format HDF est tout a fait capable de stocker un arbre XML de manière portable.
Bref, ca montre encore une fois qu'il y a un réel problème de conception, et qu'on a pour longtemps.
> D'ailleurs, XSL/T, ça a beau être super puissant, c'est tellement
> chiant à utiliser que dès que je peux éviter ben... j'évite :-)
J'avais pas osé en parlé mais comme horreur, c'est merveilleux. Dire que j'ai croisé des personnes qui ont critiqué mes Makefile sur des arguments fallacieux (en gros, c'est pas sexy ! Bon ok, la syntaxe des Makefiles a aussi des defauts). Le XSLT, c'est vraiment poussé le XML sur une mauvaise voie et ca montre clairement les limites de la syntaxe. Limite qu'on aurait pas eu avec une syntaxe de type LISP.
D'ailleurs, avec AxKit, tu peux faire des filtres en XSLT ou en XPS (XpathScript, un savant mélange de Perl et de XPath). Et bien, j'ai fait quasiment tous mes filtres en XPS ;-) Le seul défaut, c'est pas portable, le XPS n'ayant jamais percé en dehors de AxKit (dommage).
> Euh non. Contrairement à ce que vous semblez pensez tous les
> deux, les attributs sont typés
Je dis que la syntaxe des attributs n'est pas un arbre XML donc on perds la recursivité. Si tu penses que c'est bien, tant mieux pour toi. Personnellement, je trouve cela dommageable. Tant qu'on m'en a pas démontrer le contraire, je persiste à penser que c'est une erreur de conception.
> Il faut comprendre justement comment les langages de navigation
> dans les arbres XML et les langages de requêtes sur XML infèrent
> les types.
Il doit manquer des mots ;-)
J'ai fait pas mal de sites web basés sur XML avec une bonne séparation forme fond avec AxKit. Bref, je ne suis pas complètement nul même si je ne suis pas spécialiste.
> genre en XPath, si tu cherches /a//c[@d="untruc"],
Génial !
C'est pile ce que je critique. Le lien entre XPath et XML ? Syntaxe complètement différentes... Tu pourrais tout a fais appliquer XPath sur tout autre chose que le XML. Le XPath est une API de recherche dans un arbre. Ca marcherait tout aussi sur ma structure a base de parenthèse basé sur du LISP !
> Faut pas croire, les gens qui ont élaboré XML (et ceux qui
> continuent de bosser dessus) sont loin d'être bêtes.
Je n'ai jamais dis que c'etait des idiots. Une bonne partie de ces personnes venaient du SGML qui comme usine a gas est pas mal aussi ;-) Avec des raisonnements pareil, les choses n'evoluent pas.
Je reste persuadé que Knuth a été bien plus génial avec son TeX.
Je reprend ton exemple XPath avec une syntaxe LISP
En Eiffel, le concept objet est poussé a l'extrème. On le voit par exemple dans la proposition pour faire du parallélisme SCOOP (toujours aucune implémentation...).
En Sather, les concepteurs ont essayé d'orthogonaliser au maximun les concepts afin de les rendre le plus possible indépendant (concept d'orthogonalisation, si tu déplaces sur un axe, tu restes immobile sur un autre).
Donc, le concept d'héritage est divisé en deux : héritage d'interface et héritage de code. L'héritage d'interface suis le principe classique de la programmation objet lorsqu'une classe hérite d'une autre. Cependant, en Sather, elle n'hérite d'aucun code ! Il faut écrire explicitement l'héritage de code via le mot clef "include". Du coup, cela résoud très proprement les problèmes d'héritage multiple (au niveau des appels de méthodes, notament de même nom), a vrai dire, cela parait tellement simple qu'il n'y a plus de problèmes.
L'arbre des classe est très simple et permet le "supertyping". On peux créer une classe et dire que des classes déjà implémenté hérite de celle-ci !! C'est absolument génial pour étendre une librairie toute faite ou en corrigé des manques (inévitables).
Au niveau du parallélisme, les concepts en jeu sont a 100 lieu de SCOOP mais ca marche (enfin, ca marchait) et c'est clair à comprendre et a utiliser. Il y a même une extension "cluster" ou tu peux rajouter à toute instruction la chaine '@numerodunoeud" ou tu impose le noeud du cluster. Ca marche même sur les structures de donnée comme un tableau dont les éléments seraient physiquement imposés par le programmeur sur les différents noeuds du cluster.
Pour faire des boucles "loop do done", il y a un concept d'iterateur basé sur la notion de coroutine. Grace a ce concept, on évite l'usine a gas de la double structure de classe pour les conteneurs de données. L'arbre des classes n'en ai que plus simple. Grace a ce concept d'itérateur indépendant de le notion de classe et d'objet mais de même niveau que la notion de méthode, on divise par deux le nombre de classe (j'exagère) et on simplifie énormément les implémentations, laissant le compilateur optimisé le code ;-)
Bref, le langage a quelques defauts mais comme l'équipe qui l'avait développé faisait du calcul parrallèle, ils ont privilégié la simplicité et l'efficacité. Au final, on a un langage efficasse qui est un cousin d'Eiffel mais particulièrement attachant.
> Ici, il faut définir pour chaque balise une fonction particulière
Non, j'ai écris avec une syntaxe LISP mais si mes souvenirs sont bons, il faut mettre une apostrophe devant (scheme) pour dire que c'est une struture de données.
'(a (href "http://debian.org") "debian")
Bref, je ne parle pas de fonction LISP mais de structure de donnees LISP.
> En disant ça, tu ne fais que répéter ce que j'ai dit : si les attributs
> ne te plaisent pas, tu n'es pas obligé de les utiliser,
Je ne dis pas que je n'aime pas les attributs, je dis que la syntaxe n'est pas bonne. Dans mon exemple, l'attribut est en second, le contenu en troisième. Il y a bien une différence sémantique entre les attributs et le contenu.
Je me demande pourquoi se limiter a des attributs de type chaine ? Avec une vrai structure bien pensée, le contenu est un arbre et l'attribut peux aussi etre un arbre, donc une structure complexe, chose non possible aujourd'hui avec le XML au niveau des attributs.
Par exemple, la chaine href ici, tu dis que c'est une chaine. Mais en pratique, c'est une URL. On pourrait donc très bien la valider sous une forme d'URL dans le schéma en séparant le protocole (http), le serveur (debian.org) , le dossier (/)... En XML, si tu veux faire cela, tu es obligé de passer par le contenu car via les attributs, la structure de données est trop faible.
> Ou alors ils utilisent XML parce que ça fait bien, mais sans réel
> besoin : j'ai envie de flinguer à peu près tous les programmeurs
> qui utilisent XML pour faire des fichiers de config
La, je te plussoie a 100%. D'abord pour les fichiers de config, le YAML est souvent très bien. J'avoue que je déteste me tapper un XML pour configurer un logiciel.
l'attribut href est une simple chaine, pas un arbre xml. Du coup, pour injecter un truc dedans via un moteur, xslt par exemple, on a tout un tas de truc pour transformer un bout d'arbre xml en attribut et reciproquement.
Je reprend la meme chose avec un syntaxe LISP (dont je ne suis pas fanatique)
(a (href "http://debian.org") "debian")
Bilan, les atributs sont gérés comme des arbres et leur valeur peut aussi être un arbre, donc bien plus typé qu'une chaine. les atributs sont en seconde position et les valeurs en troisième. Le modèle est bien plus simple.
La structure d'arbre du XML a été cassé au niveau des attributs. C'est dommage, car une partie de récursivité est par la même perdus et donc pour s'en sortir, les API sont plus complexes.
Tout cela n'est que reflexion personnelle. Je ne me fait aucune illusion. Ce n'est pas ces quelques lignes qui vont modifier la trajectoire du XML. Je lui souhaite bonne chance.
> Le nommage des packages n'est pas basé sur le DNS, c'est un
> conseil de Sun de nommer ses packages en utilisant un nom de
> domaine qu'on possède afin de limiter au maximum les collisions
C'est ca que je reproche. Lorsque j'ai vu ca la première fois il y a ... au début de java, je me suis dis, les autres sont des idiots, cette idée est géniale.
Et bien non. Cela cloisonne les projets. En pratique, les personnes mettent effectivement le domaine dns à l'envers. On a un espace de nom qui ne veut rien dire avec des org.machin.toto...
Si tu regardes un peu du coté du CPAN, on ne perds pas son temps dans des org.machin.toto, on va directement au but et toutes les personnes du monde se partagent le MEME espace de nom. Et ca marche FORMIDABLEMENT bien. Il n'y a AUNCUNE collision !
Pourquoi, parce qu'il y a un CPAN ou tout le code de tous les modules écrit et voulant être mutualisé se trouve.
Bref, le systeme d'un seul espace de nom pousse a la mutualisation du code. Celui qui ne veut pas mutualisé peut avoir un jour un risque de collusion, tant pis pour lui (en java, c'est la meme chose pour ce point la).
Comme le code n'est pas centralisé en java, si tu veux prendre des packages d'un autre esapce de nom org.truc.titi par exemple, qu'est ce qui t'assures que ce bout de code sera encore valable dans six mois ? Bilan, tu recopies voire tu remet tout dans ton espace de nom.
Dernier point, comme chacun travaille dans son espace, si tu travaille sur un module qui fait du ping et un autre qui fait du telnet, tu peux avoir un
Comme machin et truc son dans deux esapce de nom différent, il est certain qu'il n'y a pas d'homogénéité dans la philosophie des modules ping et telnet. Au niveau du code, c'est aussi pas super explicites. On ferait un
import net.ping
import net.telnet
Ce serait quand meme bien mieux.
Ensuite, se tapper les org.machin... a chaque fois est pénible, du coup on voit souvent dans les sources des
import org.machine.*
Et ca, ca devrait être interdit par le langage. Surtout que si il y a plusieurs import de ce type et que les API sont étendues, le code peux ne plus compiler !
Un des problèmes des langages objets et que cela devient lourd parfois de faire des choses très simple. Par exemple écrire sur la sortie standard. Sans ce * dans les import en java, c'est très lourd. C'est là ou Sather a une solution GENIALE. Il y a deux classes à la racine : IN et OUT, et il y a un raccourci pour faire appel a la méthode create (ou new du C++), il suffit de mettre un # devant la classe. Donc
#OUT == OUT.create
Avec ca, écrire sur la sortie standard en pur objet tout en restant humain se fait par la seule ligne
#OUT + "hello world !\n"
On instancie la classe OUT, on appelle la méthode + sur cet objet et c'est tout !
> package : accessible uniquement depuis les instances des
> classes du même package
Désolé de mon ignorance sur ce point là. Un package est'il extensible ? Est'il lié à la notion d'espace de nom.
Mon idée est la suivante. Je veux une classe interne a mon espace de nom. En effet, elle n'a aucun intérêt a être public et je veux pouvoir modifier son API.
Mais si une autre personne étend mon espace de nom en rajoutant des classes, il a bien sur le droit d'y avoir accès puisqu'il travaille sur le même thème. Cependant, dans le contrat social implicite, il sais qu'il doit suivre la philosophie de l'espace de nom et s'adapter au changement des API interne à l'espace.
En fait, le choix de l'espace de nom, de faire un CPAN... ont plus un impact sociologoique que technique. En inscrivant dès le départ ce choix dans le langage, on inscrit le projet dans un mouvement communautaire et plutôt lié au libre. Après, la sauce marche ou ne marche pas. Dans un cadre de type INRIA, c'est intéressant de mettre ce type de base car cela évite que des pontes au dessus ai des vues plus monétaires des choses. Une fois la dynamique lancée, ils sont coincés (c'est comme ca qu'un copain a pu sauver son projet libre qui marche relativement bien et que l'université voulait récupérer a son profit).
> il y a correspondance entre chemin et nom de package. Par
> exemple la Classe org.linuxfr.Main sera dans le fichier
> org/linuxfr/Main.java
Heureusement, il faudrait être fou pour proposer un autre système... bien qu'en ada avec gnat, on a le choix de pouvoir mettre des tirets à la place des slash et donc de tout avoir à plat dans le même dossier.
> Faut savoir qu'en Lisaac, tu n'as pas de import à faire comme en perl
> ou en Java.
En Perl, il n'y a pas d'import. D'ailleurs, les import sont un truc pourri. Le seul intérêt est d'éviter d'écrire le chemin complet lorsqu'on instancie un objet. Mais le code peux ne plus compilé un jour si on fait un import * come en java ou en python.
En Perl, on fait des use ou des require. Je suis d'accord que c'est parfois un peu chiant et que cela pourrait être évité.
Cependant, le use charge le code dans la phrase de pré-compilation alors que le require ne charge le code qu'au moment de l'éxecution. La librairie n'est alors pas chargé au démarrage. Dans le cadre de gros programme ayant plein de fonctionalité, le fait de charger les modules qu'en fonction des besoins et au dernier moment est très intéressant.
De toute manière, si Lisaac veut concurrencer le C, il faudra bien qu'il supporte la compilation modulaire (des librairies et pas que des executables) et qu'il puisse charger du code dynamiquement. Imagine un peu si le code d'Apache n'était pas modulaire...
Je le sais bien d'ou mon smiley ;-) D'un autre coté, c'est sur des trucs énorme que le langage progresse...
D'ailleurs on voit bien l'intérêt de l'espace de nom. Tout ce qui concerne spécifiquement le CLAN serait sous l'espace de nom 'CLAN::'.
Très bien ta réponse sur les sections. Faut vraiment que je regarde plus du coté des langages à prototypes. En fait, j'ai évoquer ce problème d'appel à d'autres classes car je trouve que les langages classiques que je connais n'offrent pas de bonne solution de ce coté là.
> 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).
La structure de l'espace de nom ne doit surtout pas suivre l'arbre d'héritage ! Cela ne veut pas dire que les sous classes doivent être dans un autre espace de nom, bien évidement. Par contre, il y a dans un espace de nom, un ensemble de 'module' ayant un rapport commun pour faire un certain type de composant/application. Par exemple, il y a sous l'espace de nom 'Apache::' de Perl tous les modules lié au serveur web apache.
Bref, l'espace de nom est une structure 'sociale' décidé par l'homme et non par le langage. Le langage doit laisser l'homme très libre sur celui-ci.
[^] # Re: Les sources sont dispo
Posté par Sytoka Modon (site web personnel) . En réponse au journal Les premieres specification du DRM de sun son disponible. Évalué à 4.
[^] # Re: Pffff...
Posté par Sytoka Modon (site web personnel) . En réponse au journal Un compte rendu de la conf sur isaac/lisaac. Évalué à 2.
Quitte a parler du java et du C#, t'aurais pu évoquer le petit frère du C++, l'ObjectiveC, qui en ai la grande source d'inspiration.
[^] # Re: Comme promis ...
Posté par Sytoka Modon (site web personnel) . En réponse au journal Fluxbox 0.9.15. Évalué à 2.
C'est vrai que c'est pratique mais avec du recul, c'est pratique pendant combien de temps ? Combien coute de faire des "restart" ? Au bilan, tu acceptes de diminuer ta sécurité pour un problème annexe, qui ne peux pas être, a ma connaissance, dé-activé.
Sinon, nous sommes d'accord, gconf en fait bien plus que ce pour quoi il est appeller : les fichiers de configuration.
Le propre d'UNIX est la séparation des taches. A cause de ce gconf qui en fait trop, gimp n'utilise pas gconf.
Moi, ca me gonfle qu'ekiga utilise gconf pour ces parametres (/A priori/, il ne partage rien avec les autres). Ca m'oblige a avoir un daemon gconfd qui tourne.
Idem, si je fais mon propre programme. Je ne veux pas forcement avoir un daemon gconfd qui soit associé a mon programme. D'ailleurs, pour mes fichiers de configuration, j'utilise le format YAML qui est très simple et répond parfaitement au cahier des charges.
Bref, j'aime beaucoup de programmes fait avec les librairies gtk et gnome mais je n'ai pas envie d'avoir toute l'artillerie de gnome derrière pour un simple problème de configuration de mes applications (remarque, c'est pareil avec les application kde). Je ne veux pas être enfermer a choisir soit les applications gnome ou les applications kde. Je veux pouvoir piocher et utiliser les applications qui me plaisent. Bref, la base gnome a un peu trop tendance a t'enfermer dans son environnement.
[^] # Re: Spécialisé binaire ?
Posté par Sytoka Modon (site web personnel) . En réponse au message versionning de fichiers binaires. Évalué à 2.
subversion gère aussi parfaitement les méta-données. Pour les fichiers binaires, il les détecte automatiquement et n'en conserve que les xdelta de différence.
Bref, subversion est très robuste, simple.
Si tu veux un mode local, tu peux utiliser la surcouche décentralisé svk qui marche aussi très bien.
Les autres gestionnaires de versions, je ne les connais pas trop mais j'ai souvent eu l'impression qu'ils sont plus orientés code source que subversion. Par exemple, les gestionaires basé sur la notion de patch sont super bien pour améliorer le développement de code source, ca oblige a dissocier les modfications que l'on apporte en fonction d'objectif clair. L'idée derrière est de pouvoir appliquer les patch dans un autre ordre, et c'est généralement possible.
Dans le cas de fichier binaire, on est obligé de suivre l'ordre des "commit". La notion de patch a donc moins d'intérêt il me semble.
[^] # Re: Comme promis ...
Posté par Sytoka Modon (site web personnel) . En réponse au journal Fluxbox 0.9.15. Évalué à 2.
Dans un environnement gnome moderne, tu change un paramètre a un endroit et ca change partout instantanément. C'est beau mais je pense que c'est une mauvaise idée.
Le concept des UNIX est très simple. Des processus ayant des variables d'environnement qu'ils transmettre a leur fils, JAMAIS l'inverse ! Un fils a très peu de pouvoir sur un père (et réciproquement). Il faut mettre en place des outils de plus haut niveau pour faire communiquer les processus (segment de mémoire partagé...)
Pour en revenir a gconf, s'il ne remplacais que les fichiers de configuration, pourquoi tourne-t-il en mode daemon. Ce serait une simple librairie dynamique que le programme chargerait au démarrage, que ce serait très bien.
Le problème est que gconf sers aussi a partager des données entre le programmes et ce n'est pas son rôle, en tout cas, je ne suis pas de cet avis. En plus, le nombre de paramètre a partager est très faible devant la quantité de paramètre spécifique à chaque programme. Bref, que ce rôle revienne à une autre application, pourquoi pas au D-BUS...
[^] # Re: Spécialisé binaire ?
Posté par Sytoka Modon (site web personnel) . En réponse au message versionning de fichiers binaires. Évalué à 1.
Par contre, subversion fait bien tout cela. Pourquoi cherche tu autre chose sachant que tu en parles dans ta question ?
PS : par contre, ce serait bien que subversion versionne les archives (zip, tar, gz...) en versionnant leur contenu et non en global.
[^] # Re: Comme promis ...
Posté par Sytoka Modon (site web personnel) . En réponse au journal Fluxbox 0.9.15. Évalué à 2.
Si ils utilisent un bureau a distance via xvnc, tu peux leur préparer un bureau bien configuré sous icewm (comme ca ils ne sont pas trop perdus) et t'as gagné un paquet de ressources.
Avoir un utilitaire graphique qui t'aide a paramétrer, pourquoi pas. Mais faut pas non plus en faire une condition éliminatoire.
Je suis d'accord que ma phrase sur gconf était un peu hors sujet. J'ai deja pas mal posté sur gconf et je maintiens que ce truc n'est pas bon et que c'est un equivalent des variables globales. D'ailleurs, il y a un daemon gcond qui tourne en permanence (meme que parfois, ce co. survie a une fermeture de sessions...).
[^] # Re: YUM
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Disponibilité de Fedora Core 5 "Bordeaux". Évalué à 6.
Donc, je ne vois pas le problème que tu invoques, surtout que j'avais parlé de faire une API commune. Après, que chaque distribution fasse ses propres paquetages avec ses numéros de version, c'est autre chose et cela n'a rien a voir avec le gestionaire lui même.
[^] # Re: Stabilité
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Disponibilité de Fedora Core 5 "Bordeaux". Évalué à 4.
Dans la fonction publique, tu es soumis à la règle des marchés, tu n'as donc pas le choix de ce que tu achètes. DELL a perdus le marché des serveurs au CNRS et c'est NEC qui l'a. Cela veut dire que si tu achètes via le CNRS, tu te retrouves avec une machine NEC, ou alors, faut justifier que NEC ne propose pas ce que tu souhaites.
Cependant, NEC a l'air assez ouvert même si leur matériel est surtout validé pour RedHat et Novell (et Windows). Tous les moyens sont donc bons pour qu'il s'ouvre encore plus et valide un plus grand nombre de distribution, notament une base différente que la RedHat.
Il en ai de même avec pas mal de logiciels propriétaires : matlab, comsol (ex femlab)... Si tu ne les installes pas sous RedHat ou Novell, tu perds le support, et ceci même si ca marche très bien.
[^] # Re: YUM
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Disponibilité de Fedora Core 5 "Bordeaux". Évalué à 10.
C'est si dur que cela que de décrire un cahier des charges et une API et de partager ensuite le développement ?
[^] # Re: Stabilité
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Disponibilité de Fedora Core 5 "Bordeaux". Évalué à -3.
On m'a refilé un serveur sous fedora, j'attend la panne matériel pour le reformater sous debian. Rien à voir, mais si il y a du monde dans la salle, vous pouvez comme moi titiller NEC a propos de debian qui a le marché serveur au CNRS. A chaque fois que je les ais au bout du fils, je leur en parle.
[^] # Re: Comme promis ...
Posté par Sytoka Modon (site web personnel) . En réponse au journal Fluxbox 0.9.15. Évalué à 2.
Désolé mais le tout graphique avec du gconf en variable globale... c'est bien un peu mais des choses simples, c'est bien aussi.
[^] # Re: Et IPv6 ? :-)
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche WengoPhone : logiciel libre de téléphonie sur Internet. Évalué à 3.
J'ai un copain au Canada (Montréal), son fournisseur lui file une adresse IPv6, rien en IPv4. Dommage, on a jamais reussi a communiquer correctement, il y a toujours un canal qui foire.
Bref, IPv6 est déjà là.
Sinon, j'ai jamais fait de la programmation réseau mais j'avais compris qu'avec le systeme de couche, on ne se préocuppait pas trop de la couche en dessous dans tcp/ip. Il n'y a pas d'instruction pour ouvrir une socket reseau vers un nom dns et hop, ca se débrouille ?
[^] # Re: Puisqu'on cause de Gnome...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de GNOME 2.14. Évalué à 1.
Je viens de faire l'essai ce soir, c'est vrai que Nautilus ne tiens pas compte de la variable d'environnement EDITOR. Ca sers a quoi ces bonnes vielles variables ?
[^] # Re: Puisqu'on cause de Gnome...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de GNOME 2.14. Évalué à 2.
[^] # Re: Puisqu'on cause de Gnome...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de GNOME 2.14. Évalué à 5.
> que j'attend d'un éditeur de texte ...
J'ai aussi besoin de faire des selections carré, c'est à dire pouvoir sélectionner un bloc rectangulaire positionné n'importe ou et pouvoir le déplacer graphiquement. nedit fait ca super bien ;-)
Sinon, c'est vrai que le copier coller qui ne suis pas la tradition unix du bouton du milieu est fatal pour mon gedit 2.8.3. Bref, gedit, ca va pour lire un readme mais guère plus.
[^] # Re: Est-ce que Lyx ne risque pas d'être un cul-de-sac?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 2.
> des noeuds (donc des balises). D'un point de vue temps de
> définition, c'est à peu près équivalent (avec une DTD).
C'est un peu un probleme. Surtout que les noeuds sont fait pour etre un conteneur et non expliciter le noeud lui-même. Par exemple, dans une interface graphique, je peux assigner des signaux aux éléments graphiques sous forme d'attribut et mettre d'autres éléments graphiques dedans. Si je passe mes atributs sous forme de noeud, je peux avoir des clash avec les noeuds qui sont déjà la.
Il est vrai que si les attributs deviennent des arbres a part entière, la ligne de démarcation attribut/noeud sera moins claire, ce sera au schema de la préciser. Mais au moins on aura une double structure symétrique ayant une API propre laissant le développeur s'exprimer.
> Euh non. :-)
T'as raison, j'avais mal saisie la dynamique de la phrase.
Pour la suite, je suis d'accord que le développement du XML texte a dynamiser, popularisé, révolutionné (...) le développpement de librairies de recherche dans les arbres. et je trouve ca TRES BIEN. C'est le XML texte que je n'aime pas.
> XML, dans sa forme « écrite » n'a rien à voir avec ce qu'est XML
> fondamentalement.
Tu vois, on est d'accord ;-) Sauf que moi, le XML fondamentalement, je l'appelle arbre. Même que parfois, on est limité et on a la structure de graphe qui est pas mal et ce serait bien si elle profitait de la même énergie que les arbres.
> on s'en fiche un peu.
Malheureusement non. La mode Tomcat est au fichier de conf imbittable. Tu prends les fichiers de conf des modules Perl sur le CPAN, du beau YAML, c'est que du bonheur.
> NB : en TeX/LaTeX, tu as aussi des attributs, qui ne sont pas
> récursifs non plus, et qui - surprise ! - sont non ordonnés :
Attention, TeX est reprogrammable ! Si LaTeX avait eu la même énergie mise dessus que le XML, on aurait une API tip-top. Je sais qu'il y a des problèmes avec TeX mais regardes le nombre de personnes qui sont dessus. C'est quand même impressionant pour ce résultat.
> Si tu continues comme ça, tu pourrais dire qu'à part XSL/T, les
> langages de transformation de XML ne ressemblent pas trop à du
> XML.
Justement, je continue. C'est pour cela que je parle de fatras. Au moins, en TeX, tu programmes en TeX ;-)
> Et après ? XML est fait pour être lu par des machines.
Encore une fois, je suis d'accord. Mais autant prendre alors un format binaire. C'est bien plus performant. Si mes souvenirs sont bon, le format HDF est tout a fait capable de stocker un arbre XML de manière portable.
Bref, ca montre encore une fois qu'il y a un réel problème de conception, et qu'on a pour longtemps.
> D'ailleurs, XSL/T, ça a beau être super puissant, c'est tellement
> chiant à utiliser que dès que je peux éviter ben... j'évite :-)
J'avais pas osé en parlé mais comme horreur, c'est merveilleux. Dire que j'ai croisé des personnes qui ont critiqué mes Makefile sur des arguments fallacieux (en gros, c'est pas sexy ! Bon ok, la syntaxe des Makefiles a aussi des defauts). Le XSLT, c'est vraiment poussé le XML sur une mauvaise voie et ca montre clairement les limites de la syntaxe. Limite qu'on aurait pas eu avec une syntaxe de type LISP.
D'ailleurs, avec AxKit, tu peux faire des filtres en XSLT ou en XPS (XpathScript, un savant mélange de Perl et de XPath). Et bien, j'ai fait quasiment tous mes filtres en XPS ;-) Le seul défaut, c'est pas portable, le XPS n'ayant jamais percé en dehors de AxKit (dommage).
[^] # Re: Est-ce que Lyx ne risque pas d'être un cul-de-sac?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 2.
> deux, les attributs sont typés
Je dis que la syntaxe des attributs n'est pas un arbre XML donc on perds la recursivité. Si tu penses que c'est bien, tant mieux pour toi. Personnellement, je trouve cela dommageable. Tant qu'on m'en a pas démontrer le contraire, je persiste à penser que c'est une erreur de conception.
> Il faut comprendre justement comment les langages de navigation
> dans les arbres XML et les langages de requêtes sur XML infèrent
> les types.
Il doit manquer des mots ;-)
J'ai fait pas mal de sites web basés sur XML avec une bonne séparation forme fond avec AxKit. Bref, je ne suis pas complètement nul même si je ne suis pas spécialiste.
> genre en XPath, si tu cherches /a//c[@d="untruc"],
Génial !
C'est pile ce que je critique. Le lien entre XPath et XML ? Syntaxe complètement différentes... Tu pourrais tout a fais appliquer XPath sur tout autre chose que le XML. Le XPath est une API de recherche dans un arbre. Ca marcherait tout aussi sur ma structure a base de parenthèse basé sur du LISP !
> Faut pas croire, les gens qui ont élaboré XML (et ceux qui
> continuent de bosser dessus) sont loin d'être bêtes.
Je n'ai jamais dis que c'etait des idiots. Une bonne partie de ces personnes venaient du SGML qui comme usine a gas est pas mal aussi ;-) Avec des raisonnements pareil, les choses n'evoluent pas.
Je reste persuadé que Knuth a été bien plus génial avec son TeX.
Je reprend ton exemple XPath avec une syntaxe LISP
(search-xpath /a//c[@d="untruc"] '(mon-arbre-xml-ecrit-en-lisp) )
Vu comme ca, c'est sur que XPath ne s'intègre pas du tout avec un autre langage que le XML ;-)
[^] # Re: J'espère....
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 3.
En Eiffel, le concept objet est poussé a l'extrème. On le voit par exemple dans la proposition pour faire du parallélisme SCOOP (toujours aucune implémentation...).
En Sather, les concepteurs ont essayé d'orthogonaliser au maximun les concepts afin de les rendre le plus possible indépendant (concept d'orthogonalisation, si tu déplaces sur un axe, tu restes immobile sur un autre).
Donc, le concept d'héritage est divisé en deux : héritage d'interface et héritage de code. L'héritage d'interface suis le principe classique de la programmation objet lorsqu'une classe hérite d'une autre. Cependant, en Sather, elle n'hérite d'aucun code ! Il faut écrire explicitement l'héritage de code via le mot clef "include". Du coup, cela résoud très proprement les problèmes d'héritage multiple (au niveau des appels de méthodes, notament de même nom), a vrai dire, cela parait tellement simple qu'il n'y a plus de problèmes.
L'arbre des classe est très simple et permet le "supertyping". On peux créer une classe et dire que des classes déjà implémenté hérite de celle-ci !! C'est absolument génial pour étendre une librairie toute faite ou en corrigé des manques (inévitables).
Au niveau du parallélisme, les concepts en jeu sont a 100 lieu de SCOOP mais ca marche (enfin, ca marchait) et c'est clair à comprendre et a utiliser. Il y a même une extension "cluster" ou tu peux rajouter à toute instruction la chaine '@numerodunoeud" ou tu impose le noeud du cluster. Ca marche même sur les structures de donnée comme un tableau dont les éléments seraient physiquement imposés par le programmeur sur les différents noeuds du cluster.
Pour faire des boucles "loop do done", il y a un concept d'iterateur basé sur la notion de coroutine. Grace a ce concept, on évite l'usine a gas de la double structure de classe pour les conteneurs de données. L'arbre des classes n'en ai que plus simple. Grace a ce concept d'itérateur indépendant de le notion de classe et d'objet mais de même niveau que la notion de méthode, on divise par deux le nombre de classe (j'exagère) et on simplifie énormément les implémentations, laissant le compilateur optimisé le code ;-)
Bref, le langage a quelques defauts mais comme l'équipe qui l'avait développé faisait du calcul parrallèle, ils ont privilégié la simplicité et l'efficacité. Au final, on a un langage efficasse qui est un cousin d'Eiffel mais particulièrement attachant.
[^] # Re: Est-ce que Lyx ne risque pas d'être un cul-de-sac?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 2.
Non, j'ai écris avec une syntaxe LISP mais si mes souvenirs sont bons, il faut mettre une apostrophe devant (scheme) pour dire que c'est une struture de données.
'(a (href "http://debian.org") "debian")
Bref, je ne parle pas de fonction LISP mais de structure de donnees LISP.
> En disant ça, tu ne fais que répéter ce que j'ai dit : si les attributs
> ne te plaisent pas, tu n'es pas obligé de les utiliser,
Je ne dis pas que je n'aime pas les attributs, je dis que la syntaxe n'est pas bonne. Dans mon exemple, l'attribut est en second, le contenu en troisième. Il y a bien une différence sémantique entre les attributs et le contenu.
Je me demande pourquoi se limiter a des attributs de type chaine ? Avec une vrai structure bien pensée, le contenu est un arbre et l'attribut peux aussi etre un arbre, donc une structure complexe, chose non possible aujourd'hui avec le XML au niveau des attributs.
Par exemple, la chaine href ici, tu dis que c'est une chaine. Mais en pratique, c'est une URL. On pourrait donc très bien la valider sous une forme d'URL dans le schéma en séparant le protocole (http), le serveur (debian.org) , le dossier (/)... En XML, si tu veux faire cela, tu es obligé de passer par le contenu car via les attributs, la structure de données est trop faible.
'(a (href ((proto "http") (server "debian.org") (path "/")) "debian")
> Ou alors ils utilisent XML parce que ça fait bien, mais sans réel
> besoin : j'ai envie de flinguer à peu près tous les programmeurs
> qui utilisent XML pour faire des fichiers de config
La, je te plussoie a 100%. D'abord pour les fichiers de config, le YAML est souvent très bien. J'avoue que je déteste me tapper un XML pour configurer un logiciel.
[^] # Re: Est-ce que Lyx ne risque pas d'être un cul-de-sac?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 3.
Un exemple très simple
<a href="http://debian.org">debian</a>
l'attribut href est une simple chaine, pas un arbre xml. Du coup, pour injecter un truc dedans via un moteur, xslt par exemple, on a tout un tas de truc pour transformer un bout d'arbre xml en attribut et reciproquement.
Je reprend la meme chose avec un syntaxe LISP (dont je ne suis pas fanatique)
(a (href "http://debian.org") "debian")
Bilan, les atributs sont gérés comme des arbres et leur valeur peut aussi être un arbre, donc bien plus typé qu'une chaine. les atributs sont en seconde position et les valeurs en troisième. Le modèle est bien plus simple.
La structure d'arbre du XML a été cassé au niveau des attributs. C'est dommage, car une partie de récursivité est par la même perdus et donc pour s'en sortir, les API sont plus complexes.
Tout cela n'est que reflexion personnelle. Je ne me fait aucune illusion. Ce n'est pas ces quelques lignes qui vont modifier la trajectoire du XML. Je lui souhaite bonne chance.
[^] # Re: bonjour
Posté par Sytoka Modon (site web personnel) . En réponse au journal Workflow photo numérique. Évalué à 4.
[^] # Re: Euh ...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
> conseil de Sun de nommer ses packages en utilisant un nom de
> domaine qu'on possède afin de limiter au maximum les collisions
C'est ca que je reproche. Lorsque j'ai vu ca la première fois il y a ... au début de java, je me suis dis, les autres sont des idiots, cette idée est géniale.
Et bien non. Cela cloisonne les projets. En pratique, les personnes mettent effectivement le domaine dns à l'envers. On a un espace de nom qui ne veut rien dire avec des org.machin.toto...
Si tu regardes un peu du coté du CPAN, on ne perds pas son temps dans des org.machin.toto, on va directement au but et toutes les personnes du monde se partagent le MEME espace de nom. Et ca marche FORMIDABLEMENT bien. Il n'y a AUNCUNE collision !
Pourquoi, parce qu'il y a un CPAN ou tout le code de tous les modules écrit et voulant être mutualisé se trouve.
Bref, le systeme d'un seul espace de nom pousse a la mutualisation du code. Celui qui ne veut pas mutualisé peut avoir un jour un risque de collusion, tant pis pour lui (en java, c'est la meme chose pour ce point la).
Comme le code n'est pas centralisé en java, si tu veux prendre des packages d'un autre esapce de nom org.truc.titi par exemple, qu'est ce qui t'assures que ce bout de code sera encore valable dans six mois ? Bilan, tu recopies voire tu remet tout dans ton espace de nom.
Dernier point, comme chacun travaille dans son espace, si tu travaille sur un module qui fait du ping et un autre qui fait du telnet, tu peux avoir un
import org.machine.net.ping
import org.truc.net.telnet
Comme machin et truc son dans deux esapce de nom différent, il est certain qu'il n'y a pas d'homogénéité dans la philosophie des modules ping et telnet. Au niveau du code, c'est aussi pas super explicites. On ferait un
import net.ping
import net.telnet
Ce serait quand meme bien mieux.
Ensuite, se tapper les org.machin... a chaque fois est pénible, du coup on voit souvent dans les sources des
import org.machine.*
Et ca, ca devrait être interdit par le langage. Surtout que si il y a plusieurs import de ce type et que les API sont étendues, le code peux ne plus compiler !
Un des problèmes des langages objets et que cela devient lourd parfois de faire des choses très simple. Par exemple écrire sur la sortie standard. Sans ce * dans les import en java, c'est très lourd. C'est là ou Sather a une solution GENIALE. Il y a deux classes à la racine : IN et OUT, et il y a un raccourci pour faire appel a la méthode create (ou new du C++), il suffit de mettre un # devant la classe. Donc
#OUT == OUT.create
Avec ca, écrire sur la sortie standard en pur objet tout en restant humain se fait par la seule ligne
#OUT + "hello world !\n"
On instancie la classe OUT, on appelle la méthode + sur cet objet et c'est tout !
> package : accessible uniquement depuis les instances des
> classes du même package
Désolé de mon ignorance sur ce point là. Un package est'il extensible ? Est'il lié à la notion d'espace de nom.
Mon idée est la suivante. Je veux une classe interne a mon espace de nom. En effet, elle n'a aucun intérêt a être public et je veux pouvoir modifier son API.
Mais si une autre personne étend mon espace de nom en rajoutant des classes, il a bien sur le droit d'y avoir accès puisqu'il travaille sur le même thème. Cependant, dans le contrat social implicite, il sais qu'il doit suivre la philosophie de l'espace de nom et s'adapter au changement des API interne à l'espace.
En fait, le choix de l'espace de nom, de faire un CPAN... ont plus un impact sociologoique que technique. En inscrivant dès le départ ce choix dans le langage, on inscrit le projet dans un mouvement communautaire et plutôt lié au libre. Après, la sauce marche ou ne marche pas. Dans un cadre de type INRIA, c'est intéressant de mettre ce type de base car cela évite que des pontes au dessus ai des vues plus monétaires des choses. Une fois la dynamique lancée, ils sont coincés (c'est comme ca qu'un copain a pu sauver son projet libre qui marche relativement bien et que l'université voulait récupérer a son profit).
> il y a correspondance entre chemin et nom de package. Par
> exemple la Classe org.linuxfr.Main sera dans le fichier
> org/linuxfr/Main.java
Heureusement, il faudrait être fou pour proposer un autre système... bien qu'en ada avec gnat, on a le choix de pouvoir mettre des tirets à la place des slash et donc de tout avoir à plat dans le même dossier.
[^] # Re: Euh ...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
> ou en Java.
En Perl, il n'y a pas d'import. D'ailleurs, les import sont un truc pourri. Le seul intérêt est d'éviter d'écrire le chemin complet lorsqu'on instancie un objet. Mais le code peux ne plus compilé un jour si on fait un import * come en java ou en python.
En Perl, on fait des use ou des require. Je suis d'accord que c'est parfois un peu chiant et que cela pourrait être évité.
Cependant, le use charge le code dans la phrase de pré-compilation alors que le require ne charge le code qu'au moment de l'éxecution. La librairie n'est alors pas chargé au démarrage. Dans le cadre de gros programme ayant plein de fonctionalité, le fait de charger les modules qu'en fonction des besoins et au dernier moment est très intéressant.
De toute manière, si Lisaac veut concurrencer le C, il faudra bien qu'il supporte la compilation modulaire (des librairies et pas que des executables) et qu'il puisse charger du code dynamiquement. Imagine un peu si le code d'Apache n'était pas modulaire...
[^] # Re: Euh ...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 4.
Je le sais bien d'ou mon smiley ;-) D'un autre coté, c'est sur des trucs énorme que le langage progresse...
D'ailleurs on voit bien l'intérêt de l'espace de nom. Tout ce qui concerne spécifiquement le CLAN serait sous l'espace de nom 'CLAN::'.
Très bien ta réponse sur les sections. Faut vraiment que je regarde plus du coté des langages à prototypes. En fait, j'ai évoquer ce problème d'appel à d'autres classes car je trouve que les langages classiques que je connais n'offrent pas de bonne solution de ce coté là.
> 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).
La structure de l'espace de nom ne doit surtout pas suivre l'arbre d'héritage ! Cela ne veut pas dire que les sous classes doivent être dans un autre espace de nom, bien évidement. Par contre, il y a dans un espace de nom, un ensemble de 'module' ayant un rapport commun pour faire un certain type de composant/application. Par exemple, il y a sous l'espace de nom 'Apache::' de Perl tous les modules lié au serveur web apache.
Bref, l'espace de nom est une structure 'sociale' décidé par l'homme et non par le langage. Le langage doit laisser l'homme très libre sur celui-ci.