D'une part un passage de Irix à Linux n'est pas si savoureux que ça rapport à Microsoft, d'autre part tu trouves savoureux que la compta, l'étiquettage ou encore le graphisme à Mandriva soit faite sous Windows ou MacOS ? Que RMS utilise un BIOS et un microcode propriétaires sur son laptop ? Bref.
Il faut en vouloir pour conclure la même chose que toi à la lecture de ce document ! Ca parait plus un document de travail, c'est fouilli, on ne sait pas ce qui a été fait, ce qui va etre fait, on ne sait pas vraiment pourquoi.
>texte en français (quelle utilité ?).
Je ne répondrai pas à cette affirmation, mais juste une interrogation à gc : pourquoi utilise t il encore le français, c'est tellement ringard^M^Mhasbeen ?
Et si tu essayais de ne pas partir obligatoirement du point de vue du complot mondial ?
Je parlais de « fichiers texte en français », ce que ta citation a opportunément coupé en deux ; et en particulier leur problème c'est qu'il n'est pas fait mention de leur codage. Bien sûr que je manipule du texte en français, et pour cela si j'utilise OOo, un fichier html, un fichier xml, ou encore un .po, le codage étant déclaré, aucun problème ne se pose.
Pour finir, je te propose de juger de ta question provocatrice et stupide en te rappelant que je suis le traducteur anglais->français de plusieurs FAQ et de plusieurs logiciels libres.
Sinon pour convertir son système de fichier en utf-8 rien de plus simple :
Tu devrais mieux lire ce que voulait l'auteur de la question initiale pour éviter de répondre le contraire de ce qui est demandé.
-Problemes de compatibilite entre les anciens fichier textes et les nouveaux
c'est normal, un fichier texte ne précise pas le codage utilisé, et il n'y a pas de moyen fiable de le détecter. il faut que tu passes à la main su ta collection de fichiers texte.
cependant, j'ai passé ma machine en utf8 il y a 6 mois (besoin de manipuler à la fois des accents français et des caractères arabes), et je n'ai jamais eu ce problème. il faut dire que je n'ai pas de fichiers texte en français (quelle utilité ?).
-Problemes de compatibilite en cas de copie sur une autre machine
copie de ? fichier texte ? il faut transcoder à la volée bien sûr si l'autre machine n'est pas en utf8.
# cat fichier | iconv -f utf8 -t latin1
-Problemes de correction orthographique
sûrement un bug dans l'application. je parierais qu'il est corrigé depuis le temps.
Bref que du bonheur
c'est clair qu'il faut avoir intérêt à passer en utf8 pour en supporter les conséquences néfastes.
je me demandais donc si il y avait une maniere simple de repasser de l'UTF-8 a l'iso 88 machin ( mais si vous savez ... )
la locale du système c'est le plus simple dans l'histoire (utiliser localedrake ou éditer à la main le /etc/sysconfig/i18n). le problème derrière c'est le codage des noms de fichier dans un certain nombre de systèmes de fichier (voir dans /etc/fstab). cependant sur le fond c'est chercher la merde et assez inutile d'utiliser des caractères non ascii (et des espaces) dans les noms de fichier (sauf à rester dans une utilisation très basique du système).
bref c'est possible mais il te faudra ajuster des trucs et c'est pas forcément très fun (si tu as un /home séparé, pourquoi pas réinstaller le système, en plus tu pourrais prendre une 2006 au passage).
Je pense qu'hériter au lieu d'utiliser est une mauvaise chose car ce sont deux mécanismes conceptuellement différents. Ce que tu proposes c'est d'utiliser l'héritage à la place de l'agrégation pour
- raccourcir le code (mauvaise raison) ;
- simuler un mixin (meilleure raison mais encore faut-il :
1. le savoir ;
2. le noter (commentaires)).
Je propose d'hériter puisque lorsque je veux éditer visuellement une forme, le "concept" dont j'ai besoin est clairement pour moi "une forme qui possède des propriétés supplémentaires", donc ça me parait clair que ca tient complètement de "is_a" et pas du tout de "has_a". Une forme visuellement éditable est une forme, et en plus elle est visuellement éditable.
Maintenant, tout ce que je dis ne sert à rien et n'avancera à rien si, comme pourrait sembler le faire penser l'exemple Laguna, tu ne fais pas la différence entre hériter et utiliser.
Au moins tu n'y vas pas avec le dos de la cuillère.
perl est difficile a maintenir si l'on approche perl comme n'importe quel autre langage.
Pas d'accord. Perl est difficile à maintenir parce qu'il y a tellement de façons de faire quelque chose, que si toi tu lis du code que moi j'aurais écris avec mes habitudes et préférences, à tous les coups tu vas le trouver illisible. Et inversement bien sûr. Et si tu dois améliorer/changer mon code, tes changements seront illisibles pour moi.
La multiplicité des styles de programmation en Perl est sûrement un avantage pour l'écriture car les gens "trouvent" un style proche de leur approche et leur façon de faire, par contre c'est un inconvénient pour la maintenabilité du code dans une grande équipe (moi je bannis "unless" que je trouve illisible, ce genre de détail à la con).
Je ne vois pas d'ailleurs en quoi le fait qu'il ne faille pas l'aborder comme les autres langages solutionne quoi que ce soit au niveau de la maintenabilité du code.
pour donner un exemple, ecrire la doc d'une feuille d'impots est un exercice à plusieurs mains, il faut que cela soit le plus homogene possible sinon c'est inmaintenable.
Je ne vois pas du tout où tu veux en venir dans ce post. Je pense que tu n'illustres pas assez. Bon ton exemple avec l'enfant et le ballon est drôle. Ceci dit, Larry Wall est un linguiste à ma connaissance, donc je pense que tu creuses un point intéressant de son approche à son langage.
un extrait de code pour le SMTP genericisé ( commentaire d'origine ;) ) :
Si j'ai bien compris, tu construis un objet HA::Net::SMTP puis tu le précises dans les méthodes helo et ehlo. C'est effectivement un side-effect élégant de la syntaxe de création des objets en Perl, j'acquièsce vigoureusement. Maintenant, est-ce que l'intérêt est suffisant pour contrebalancer la ligne « bless » supplémentaire nécessaire pour tous les objets qui n'auront jamais besoin de cette fonctionalité ? Je n'en suis pas vraiment sûr. En plus, Perl pourrait suivre la convention de faire un bless implicite sur la valeur de retour de la fonction "new" avec le nom de package adéquat, si cette valeur n'est pas déjà un objet (ça a peut-être été écarté pour raisons de compatibilités avec les anciens programmes perl non objet utilisant la fonction new ? bon un tel problème n'a pas empêché d'ajouter l'appel implicite de DESTROY).
outre divers cas de timtowtdi pour de l'heritage multiple, des cas :
ok mais du code ?
mais bizarrement, ce n'est pas parce qu'il n'y a qu'une seule solution que tout le monde va y arriver, cela part d'une sous evaluation colossale de l'imagination de l'etre humain.
Rappelle-toi aussi que du code Perl est plus difficile à maintenir que d'autres langages à cause justement du grand nombre de styles utilisés par les programmeurs Perl. C'est un problème.
Moi non plus comme Sylvain je ne vois pas le besoin d'héritage multiple dans ces exemples.
On peut très bien s'en passer à mon avis.
Alors montre concrètement comment faire pour modéliser l'exemple avec les formes géométriques.
Si on rencontre des cas où on a besoin d'hériter de plusieurs classes à la fois, n'est ce pas parce que la classe mère n'est pas assez complète ?
Tu restes dans la théorie. Raisonne sur mon exemple. Je ne vois pas en quoi les classes mères de formes géométrique ou la classe mère des formes éditables graphiquement sont incomplètes.
J'en profite pour répondre à sa réponse pour pas te laisser faire la même :
- ou tu sépares proprement application et interface (c'est-à-dire que tu fais un modèle pour le calcul, un modèle-proxy pour donner à l'UI et une UI (avec ses objets à elle : widgets de toutes sortes)) ;
Ca veut dire quoi séparer proprement ? Je vais pas m'amuser à dupliquer (proxy) pour le plaisir d'avoir un beau design qui plait aux théoriciens. Avoir plusieurs classes permet de "séparer", et au contraire je trouve bien plus élégant de réutiliser dans l'interface des composants du backend (hériter de ses classes). On est ici dans un cas de réutilisabilité utile et pratique.
Dans la pratique, le backend définit des classes pour des formes géométriques avec des données précises ; dans l'interface je veux éditer ces formes géométriques, je trouve ça troublant de suggérer de ne pas utiliser ces classes existantes.
- ou tu ne fais qu'un modèle qui mélange à la fois les structures et les services pour le calcul et pour l'UI.
Je ne comprends pas ce que ça veut dire (est-ce que parler de « services » est une façon cachée de parler d'interfaces ?).
Je parle de Perl. En réponse tu sors un des pires langages, je vois pas ce que ça prouve. On peut toujours trouver pire. En C aussi tu peux « faire de l'objet » mais c'est pire qu'en Perl, on est d'accord.
Pour ce qui est de bless, l'enorme interet de cette instruction est de changer de classe un objet. J'utilise entre autre bless pour faire des fabriques d'objets et pour faire muter un objet ( genre des werewolf objects ;) ).
Hum, a premiere vue ca me semble logique de devoir explicitement prévoir les changements de classe (après tout on prévoit explicitement les constructions, vu qu'un changement de classe c'est une construction partielle, ça me parait normal d'avoir un cas spécialisé pour ca). Donne-moi un exemple en Perl, ce sera peut-etre plus parlant.
Le plus impressionnant doit etre celui de Shanghai (aeroport<=>quartier d'affaire de Pudong), qui est le plus rapide de la planète avec plus de 400Km/h...
Euh. Y'a combien de distance à parcourir ? Avec le temps d'accélération et de freinage...
3. la POO en perl est de la POO classique mais faite en perl.
Elle est lourde car elle manque de sucre. Je parle de la construction d'objet avec « bless » explicite, et de l'obligation de passer l'instance comme premier paramètre des méthodes.
Voir l'exemple avec les formes géométriques et le besoin d'héritage multiple lorsqu'on veut faire un éditeur graphique pour ces formes, dont je parle un peu plus haut en réponse à Sylvain.
Le support du multiple dispatch ("honorer" les multi-méthodes) est le fait qu'en cas de polymorphisme présentant plusieurs implémentations du même nom de méthode avec le même nombre de paramètres, où uniquement le type des paramètres de la méthode varie, le langage arrive à choisir la bonne méthode en explorant le type réel des arguments. Java ne disposant pas de cette fonctionnalité, le code suivant utilisera deux fois la méthode foo(Object) alors que dans le deuxième cas, le paramètre étant de type String il y a une "meilleure" méthode à utiliser. C'est une simplification de l'implémentation du langage (et une possibilité supplémentaire d'optimisation). En pratique pour mon cas personnel, il est rare que je me heurte à ce problème (mais ça peut être chiant lorsqu'on manipule génériquement des collections d'objets hétérogènes avec des méthodes spécialisées pour les types possibles, et ça m'est arrivé).
-=-=----=-=----=-=----=-=----=-=----=-=----=-=----=-=---
public static void foo(String s) {
System.out.println("foo(String s)");
}
public static void foo(Object o) {
System.out.println("foo(Object o)");
}
public static void main( String args[] ) throws IOException {
Object m = null;
foo(m);
m = "";
foo(m);
}
-=-=----=-=----=-=----=-=----=-=----=-=----=-=----=-=---
Donne :
foo(Object o)
foo(Object o)
Noter qu'on peut forcer la sélection de la bonne méthode avec, si cela s'y prète (mais c'est bien crade) :
foo((String)m);
Une observation parallèle intéressante est qu'en java, "null" peut être implicitement typé. En effet, foo((String)null) et foo((Object)null) sont valides et permettent de sélectionner entre les deux méthodes foo :)
Et, à ce moment, l'on s'était rendu compte que l'héritage multiple posait beaucoup de problèmes et qu'il fallait faire une différence entre l'héritage de structure (classes) et l'héritage de comportements (interfaces).
Pourquoi ?
Quand je me heurte concrètement à ce problème, les interfaces ne sont pas une solution pratique parce que je veux attacher des données ou du code en plus de l'API.
On s'est aussi rendu compte que la majorité des problèmes de l'héritage multiple sont dus à l'héritage multiple de structures (problèmes de l'héritage en diamant, p.ex.).
C'est a dire ? L'héritage en diamant me semble poser un problème dans l'implémentation du langage, pas pour le programmeur, je me trompe ?
On s'est aussi rendu compte que les autres cas d'héritage multiple sont relativement rares (comparativement aux ennuis) et facilement contournables par délégation.
D'une part je continue à penser que ça m'arrive bien plus souvent que le manque de multiméthodes, même si je suis d'accord que le besoin ne s'en fait pas sentir tous les jours[1]. D'autre part je continue à ne pas apprécier la délégation qui impose du code "dupliqué" au kilomètre.
tu fais plusieurs choix discutables, p.ex. que Laguna est une classe et que Renaut est une classe. Voiture est bien une classe, mais Renault est une instance de la classe Constructeur et Laguna une instance de la classe Modèle. Voiture aura donc deux attributs : constructeur et modèle.
C'est un exemple rapidement fait pour montrer qu'on peut avoir besoin de d'hériter de deux classes distinctes. D'ailleurs quelle est vraiment la différence ave le fait d'hériter d'une classe et d'implémenter une ou plusieurs interfaces ? Conceptuellement, on "suit", on "adhère" à différents "traits", "comportements", la seule différence est qu'on partage aussi des données ou du code dans un cas et pas dans l'autre. Je considère donc une interface comme une classe "réduite" mais je serais content qu'on me convainque du contraire ?
Je vais te donner un autre cas concrêt qu'il m'est arrivé, et dis-moi ce que tu penses de la conception.
Nous avons un ensemble de formes géométriques : Ligne, Rectangle, Polygone. On utilise une classe pour chacun, ce qui permet de stocker des données comme les deux points d'une Ligne ou les quatre points d'un Rectangle par exemple. On les manipule dans une application de calcul scientifique pour générer des espaces discrets.
D'autre part, nous avons un éditeur graphique pour dessiner des formes géométriques. Chaque forme géométrique devra donc implémenter certains comportements supplémentaires, comme se dessiner dans un espace graphique, mais elles ont aussi toutes en commun de posséder une couleur. Cette couleur est une donnée, et on veut rajouter des accesseurs pour la manipuler. On veut aussi rajouter du code (une méthode) pour marquer visuellement que cette forme est sélectionnée (la couleur passera à une couleur fixée, le gris en l'occurrence). Cela a été implémenté (en C++) par une classe mère GtkForme, chaque forme géométrique héritant ensuite de cette classe pour obtenir la couleur, et de sa classe de forme géométrique de base pour hériter de ses coordonnées.
Est-ce une mauvaise conception ? A cause du manque de l'héritage multiple, je ne sais pas comment faire ça élégamment en Java.
Alors tu me répondras : c'est de la délégation, c'est plus joli avec de l'héritage. Mais l'héritage n'a rien à voir dans ces relations. Le fait que tu puisses remplacer de l'utilisation (composition/aggrégation) par de l'héritage et que cela soit plus court à écrire n'est pas une raison pour le faire. Conceptuellement, ça ne tient pas.
Uniquement parce que dans mon exemple tu suggères de remplacer des classes par des instances ? Est-ce que tu peux m'expliquer pourquoi il est conceptuellement correct d'avoir un héritage simple et de l'implémentation d'interface(s), mais pas correct d'avoir un héritage multiple ? (en fait cette question se rapproche beaucoup de ma question du paragraphe précédent)
Enfin, pour mettre en perspective la pensée que l'héritage multiple est un symptôme de mauvaise conception, je citerais le fameux Craig R. McClanahan (monsieur struts, un des monsieur tomcat) dans la javadoc de org.apache.catalina.core.ApplicationHttpRequest (source de tomcat donc ) :
* WARNING: Due to Java's lack of support for multiple
* inheritance, all of the logic in ApplicationRequest is
* duplicated in ApplicationHttpRequest. Make sure that you
* keep these two classes in synchronization when making changes!
[1] je rapproche d'ailleurs ce problème du manque de destructeur dans les GC dits "modernes" ou "vrais" (java, ruby) avec mark & sweep, par rapport aux GC dits "faux" (perl, python) fonctionnant par compteur de référence ; concrètement il est assez rare d'avoir besoin de destructeurs vrais (c'est à dire qui sont vraiment appelés quand l'objet est déscopé), mais quand on en a besoin c'est très chiant de ne pas en avoir ; surtout utile pour les IOs, et les gens de jakarta-httpclient (pour java) sont obligés d'imposer un HttpMethod#releaseConnection bien crade et bien chiant à cause de ça.
De mon côté j'ai déjà eu plusieurs cas où une multi-méthode aurait permis une factorisation élégante de mon code ! A la place ... bah je suis obligé de dupliquer ...
En Java (je ne suis pas sur que tu parles de Java encore ou pas) je choisirais l'héritage multiple bien avant les multiméthodes. A cause du manque d'héritage multiple on se retrouve obligé de faire de la délégation kilométrique (ou pire). A mon avis ça manque bien plus.
D'ailleurs à propos du manque d'héritage multiple, je me heurte sans arrêt aux javaïens qui me disent qu'il faut « concevoir différemment » mais je cherche toujours une solution au problème simple suivant :
Si les bugs sont rares, c'est parce que faire une erreur ca coûte très cher - avec des jeux de masques qui coûtent actuellement dans les 50M d'euros, et qu'il faut refaire dès qu'il y a une correction à apporter, on fait gaffe. Le problème, c'est que info beaucoup de développeurs se disent que c'est pas très grave s'il y a des bugs, ils pourront toujours ressortir une nouvelle version.
Et ils ont raison, tu le démontres toi même :)
D'ailleurs faire des programmes prouvés c'est possible, c'est réalisé dans certains domaines critiques/importants. Et même par exemple dans les jeux vidéos pour console il y a très peu de bugs puisque l'éditeur sait très bien qu'il ne pourra pas patcher.
il reste ces 10% où les gens imaginent des convonlutions invraisemblables pour combler le manque de multi-méthode (i.e. de méthodes résolues sur plusieurs arguments et non un seul). Et à ma connaissance, seul LISP dans les langages répandus permet la création de multi-méthodes.
Je suis pas du tout convaincu. Dans la pratique c'est vachement rare de se faire flinguer par le manque de multiméthodes. Par exemple je vais du java au taf (ne moquez pas, ça me permet de me nourrir et de rester propre), c'est surtout le manque de sucre fonctionnel qui fait chier (et d'ailleurs le prochain C# en aura beaucoup apparemment), style map/grep, initialisation de listes statiques, fermetures. Après, ça dépend peut-être du type de programme et des connaissances ou du style du programmeur...
En quoi n'est-ce pas une perte de temps et d'argent, du point de vue du gestionnaire d'une entreprise ?
Je rappelle que « la société » ne demande pas au gestionnaire d'une entreprise d'adopter un point de vue moral ou social. On lui demande uniquement d'équilibrer ses comptes et d'avoir de bonnes perspectives d'avenir (accessoirement pour celles qui sont en Bourse, on leur demande 15% de taux de rentabilité).
NB : je ne décris pas ce que je veux/voudrais/aime/préfère, je décris la réalité.
Si l'optique de la contribution est l'amélioration du produit, c'est très criticable : ce n'est pas un ou quelques contributeurs isolés qui permettront à un projet d'une certaine envergure d'éviter de sombrer, si le reste du monde s'en désintéresse.
Personnellement j'ai contribué (petitement) à quelques projets libres dans le cadre de mon travail et ça ne change pas d'un iota les perspectives des projets (ni mes connaissances globales sur ces projets).
Ma critique était aussi dirigée contre paypal, qui se sucre pas mal, et qui se montre être totalement irrespectueux de ses clients (acheteur comme vendeur).
Je +++. J'habite en Suisse, sur leur interface de daube le premier truc à choisir c'est le pays de résidence. Une fois que j'ai choisi la Suisse, l'interface passe magiquement en Allemand (langue de la majorité des Suisses) et je n'y comprends plus rien. Bien sûr, aucune option, rien pour changer, même l'anglais à la limite, nada. J'ai envoyé un mail, j'ai reçu une réponse automatique navrante. J'ai du mal à filer mon numéro de carte de crédit en confiance sur une interface dont je ne comprends même pas ce que veut dire les boutons de confirmation ou d'annulation.
Ce problème pourrait (en partie) se régler par une licence adaptée aux services (style GPLv3 qui est encore à l'étude) précisant que fournir un service basé sur ce logiciel oblige à fournir le code source des programmes utilisés pour fournir ce service, sous la même licence.
C'est pas vraiment ça qui est proposé. Ce qui est proposé, c'est que si le logiciel libre d'origine dispose d'une commande permettant aux « utilisateurs » du logiciel de télécharger le code source de ce logiciel, alors tout utilisateur, donc les boîtes aussi, doivent conserver cette commande. Et en plus, c'est encore à l'étude. Concrètement, il faut donc quand même que d'une part l'auteur du logiciel libre d'origine mette cette commande, et que cela s'y prète. Par exemple, pour le kernel je ne vois pas de moyen de le faire à moins de mettre un truc bien crade dans le kernel space. À mon avis, ce ne sera pas au point de rendre les business existants sur le libre (ce que fait google par exemple) bien plus difficiles (et heureusement) (enfin question de point de vue après tout).
Je cite RMS dans sa dernière interview :
We're looking at an approach where programs used in this way [NDM : comme « services »] will have to include a command for the user to download the source for the version that is running.
But this will not apply to all GPL-covered programs, only to programs that already contain such a command. Thus, this change would have no effect on existing software, but developers could activate it in the future.
This is only a tentative plan, because we have not finished studying the matter to be sure it will work.
If you release a program that implements such a command, GPL 3 will require others to keep the command working in their modified versions of the program.
# une réponse
Posté par gc (site web personnel) . En réponse au message pb avec postfix. Évalué à 1.
[^] # Re: casquette
Posté par gc (site web personnel) . En réponse au journal Après la danse pour développeurs..... Évalué à 2.
[^] # Re: mouais
Posté par gc (site web personnel) . En réponse au journal Microsoft developpe sous Linux. Évalué à 3.
# meuh
Posté par gc (site web personnel) . En réponse à la dépêche La distribution Mandriva GNU/Linux est prête pour 2006. Évalué à 5.
http://qa.mandriva.com/twiki/bin/view/Main/SystemInitializat(...)
Il faut en vouloir pour conclure la même chose que toi à la lecture de ce document ! Ca parait plus un document de travail, c'est fouilli, on ne sait pas ce qui a été fait, ce qui va etre fait, on ne sait pas vraiment pourquoi.
[^] # Re: Migration vers UTF-8
Posté par gc (site web personnel) . En réponse au message (LE 2005) UTF8 --> Iso 88.... Évalué à 1.
Je ne répondrai pas à cette affirmation, mais juste une interrogation à gc : pourquoi utilise t il encore le français, c'est tellement ringard^M^Mhasbeen ?
Et si tu essayais de ne pas partir obligatoirement du point de vue du complot mondial ?
Je parlais de « fichiers texte en français », ce que ta citation a opportunément coupé en deux ; et en particulier leur problème c'est qu'il n'est pas fait mention de leur codage. Bien sûr que je manipule du texte en français, et pour cela si j'utilise OOo, un fichier html, un fichier xml, ou encore un .po, le codage étant déclaré, aucun problème ne se pose.
Pour finir, je te propose de juger de ta question provocatrice et stupide en te rappelant que je suis le traducteur anglais->français de plusieurs FAQ et de plusieurs logiciels libres.
Sinon pour convertir son système de fichier en utf-8 rien de plus simple :
Tu devrais mieux lire ce que voulait l'auteur de la question initiale pour éviter de répondre le contraire de ce qui est demandé.
[^] # Re: re
Posté par gc (site web personnel) . En réponse au message aidez moi. Évalué à 4.
# meuh
Posté par gc (site web personnel) . En réponse au message (LE 2005) UTF8 --> Iso 88.... Évalué à 1.
c'est normal, un fichier texte ne précise pas le codage utilisé, et il n'y a pas de moyen fiable de le détecter. il faut que tu passes à la main su ta collection de fichiers texte.
cependant, j'ai passé ma machine en utf8 il y a 6 mois (besoin de manipuler à la fois des accents français et des caractères arabes), et je n'ai jamais eu ce problème. il faut dire que je n'ai pas de fichiers texte en français (quelle utilité ?).
-Problemes de compatibilite en cas de copie sur une autre machine
copie de ? fichier texte ? il faut transcoder à la volée bien sûr si l'autre machine n'est pas en utf8.
# cat fichier | iconv -f utf8 -t latin1
-Problemes de correction orthographique
sûrement un bug dans l'application. je parierais qu'il est corrigé depuis le temps.
Bref que du bonheur
c'est clair qu'il faut avoir intérêt à passer en utf8 pour en supporter les conséquences néfastes.
je me demandais donc si il y avait une maniere simple de repasser de l'UTF-8 a l'iso 88 machin ( mais si vous savez ... )
la locale du système c'est le plus simple dans l'histoire (utiliser localedrake ou éditer à la main le /etc/sysconfig/i18n). le problème derrière c'est le codage des noms de fichier dans un certain nombre de systèmes de fichier (voir dans /etc/fstab). cependant sur le fond c'est chercher la merde et assez inutile d'utiliser des caractères non ascii (et des espaces) dans les noms de fichier (sauf à rester dans une utilisation très basique du système).
bref c'est possible mais il te faudra ajuster des trucs et c'est pas forcément très fun (si tu as un /home séparé, pourquoi pas réinstaller le système, en plus tu pourrais prendre une 2006 au passage).
[^] # Re: Mes deux centimes ...
Posté par gc (site web personnel) . En réponse au journal Repenser les langages et le développement logiciel. Évalué à 1.
- raccourcir le code (mauvaise raison) ;
- simuler un mixin (meilleure raison mais encore faut-il :
1. le savoir ;
2. le noter (commentaires)).
Je propose d'hériter puisque lorsque je veux éditer visuellement une forme, le "concept" dont j'ai besoin est clairement pour moi "une forme qui possède des propriétés supplémentaires", donc ça me parait clair que ca tient complètement de "is_a" et pas du tout de "has_a". Une forme visuellement éditable est une forme, et en plus elle est visuellement éditable.
Maintenant, tout ce que je dis ne sert à rien et n'avancera à rien si, comme pourrait sembler le faire penser l'exemple Laguna, tu ne fais pas la différence entre hériter et utiliser.
Au moins tu n'y vas pas avec le dos de la cuillère.
[^] # Re: Heu, perl ?
Posté par gc (site web personnel) . En réponse au message Qui m'aime me suive !!. Évalué à 1.
Pas d'accord. Perl est difficile à maintenir parce qu'il y a tellement de façons de faire quelque chose, que si toi tu lis du code que moi j'aurais écris avec mes habitudes et préférences, à tous les coups tu vas le trouver illisible. Et inversement bien sûr. Et si tu dois améliorer/changer mon code, tes changements seront illisibles pour moi.
La multiplicité des styles de programmation en Perl est sûrement un avantage pour l'écriture car les gens "trouvent" un style proche de leur approche et leur façon de faire, par contre c'est un inconvénient pour la maintenabilité du code dans une grande équipe (moi je bannis "unless" que je trouve illisible, ce genre de détail à la con).
Je ne vois pas d'ailleurs en quoi le fait qu'il ne faille pas l'aborder comme les autres langages solutionne quoi que ce soit au niveau de la maintenabilité du code.
pour donner un exemple, ecrire la doc d'une feuille d'impots est un exercice à plusieurs mains, il faut que cela soit le plus homogene possible sinon c'est inmaintenable.
Je ne vois pas trop le rapport :)
j'avais ecrit ce post sur usenet a propos de perl ( effectivement cité sur wikipedia http://fr.wikipedia.org/wiki/Perl_%28langage%29(...)(...) ) :
http://groups.google.fr/group/fr.comp.lang.perl/msg/f8e35176b2448bb(...)
Je ne vois pas du tout où tu veux en venir dans ce post. Je pense que tu n'illustres pas assez. Bon ton exemple avec l'enfant et le ballon est drôle. Ceci dit, Larry Wall est un linguiste à ma connaissance, donc je pense que tu creuses un point intéressant de son approche à son langage.
un extrait de code pour le SMTP genericisé ( commentaire d'origine ;) ) :
Si j'ai bien compris, tu construis un objet HA::Net::SMTP puis tu le précises dans les méthodes helo et ehlo. C'est effectivement un side-effect élégant de la syntaxe de création des objets en Perl, j'acquièsce vigoureusement. Maintenant, est-ce que l'intérêt est suffisant pour contrebalancer la ligne « bless » supplémentaire nécessaire pour tous les objets qui n'auront jamais besoin de cette fonctionalité ? Je n'en suis pas vraiment sûr. En plus, Perl pourrait suivre la convention de faire un bless implicite sur la valeur de retour de la fonction "new" avec le nom de package adéquat, si cette valeur n'est pas déjà un objet (ça a peut-être été écarté pour raisons de compatibilités avec les anciens programmes perl non objet utilisant la fonction new ? bon un tel problème n'a pas empêché d'ajouter l'appel implicite de DESTROY).
[^] # Re: Heu, perl ?
Posté par gc (site web personnel) . En réponse au message Qui m'aime me suive !!. Évalué à 1.
ok mais du code ?
mais bizarrement, ce n'est pas parce qu'il n'y a qu'une seule solution que tout le monde va y arriver, cela part d'une sous evaluation colossale de l'imagination de l'etre humain.
Rappelle-toi aussi que du code Perl est plus difficile à maintenir que d'autres langages à cause justement du grand nombre de styles utilisés par les programmeurs Perl. C'est un problème.
[^] # Re: Mes deux centimes ...
Posté par gc (site web personnel) . En réponse au journal Repenser les langages et le développement logiciel. Évalué à 3.
On peut très bien s'en passer à mon avis.
Alors montre concrètement comment faire pour modéliser l'exemple avec les formes géométriques.
Si on rencontre des cas où on a besoin d'hériter de plusieurs classes à la fois, n'est ce pas parce que la classe mère n'est pas assez complète ?
Tu restes dans la théorie. Raisonne sur mon exemple. Je ne vois pas en quoi les classes mères de formes géométrique ou la classe mère des formes éditables graphiquement sont incomplètes.
J'en profite pour répondre à sa réponse pour pas te laisser faire la même :
- ou tu sépares proprement application et interface (c'est-à-dire que tu fais un modèle pour le calcul, un modèle-proxy pour donner à l'UI et une UI (avec ses objets à elle : widgets de toutes sortes)) ;
Ca veut dire quoi séparer proprement ? Je vais pas m'amuser à dupliquer (proxy) pour le plaisir d'avoir un beau design qui plait aux théoriciens. Avoir plusieurs classes permet de "séparer", et au contraire je trouve bien plus élégant de réutiliser dans l'interface des composants du backend (hériter de ses classes). On est ici dans un cas de réutilisabilité utile et pratique.
Dans la pratique, le backend définit des classes pour des formes géométriques avec des données précises ; dans l'interface je veux éditer ces formes géométriques, je trouve ça troublant de suggérer de ne pas utiliser ces classes existantes.
- ou tu ne fais qu'un modèle qui mélange à la fois les structures et les services pour le calcul et pour l'UI.
Je ne comprends pas ce que ça veut dire (est-ce que parler de « services » est une façon cachée de parler d'interfaces ?).
[^] # Re: Heu, perl ?
Posté par gc (site web personnel) . En réponse au message Qui m'aime me suive !!. Évalué à 2.
Je parle de Perl. En réponse tu sors un des pires langages, je vois pas ce que ça prouve. On peut toujours trouver pire. En C aussi tu peux « faire de l'objet » mais c'est pire qu'en Perl, on est d'accord.
Pour ce qui est de bless, l'enorme interet de cette instruction est de changer de classe un objet. J'utilise entre autre bless pour faire des fabriques d'objets et pour faire muter un objet ( genre des werewolf objects ;) ).
Hum, a premiere vue ca me semble logique de devoir explicitement prévoir les changements de classe (après tout on prévoit explicitement les constructions, vu qu'un changement de classe c'est une construction partielle, ça me parait normal d'avoir un cas spécialisé pour ca). Donne-moi un exemple en Perl, ce sera peut-etre plus parlant.
[^] # Re: Copain
Posté par gc (site web personnel) . En réponse au sondage Nombre de pays où je suis passé :. Évalué à 2.
Euh. Y'a combien de distance à parcourir ? Avec le temps d'accélération et de freinage...
[^] # Re: Heu, perl ?
Posté par gc (site web personnel) . En réponse au message Qui m'aime me suive !!. Évalué à 2.
Elle est lourde car elle manque de sucre. Je parle de la construction d'objet avec « bless » explicite, et de l'obligation de passer l'instance comme premier paramètre des méthodes.
[^] # Re: Mes deux centimes ...
Posté par gc (site web personnel) . En réponse au journal Repenser les langages et le développement logiciel. Évalué à 2.
# meuh
Posté par gc (site web personnel) . En réponse au message C'est quoi le multi-méthode ?. Évalué à 6.
-=-=----=-=----=-=----=-=----=-=----=-=----=-=----=-=---
public static void foo(String s) {
System.out.println("foo(String s)");
}
public static void foo(Object o) {
System.out.println("foo(Object o)");
}
public static void main( String args[] ) throws IOException {
Object m = null;
foo(m);
m = "";
foo(m);
}
-=-=----=-=----=-=----=-=----=-=----=-=----=-=----=-=---
Donne :
foo(Object o)
foo(Object o)
Noter qu'on peut forcer la sélection de la bonne méthode avec, si cela s'y prète (mais c'est bien crade) :
foo((String)m);
Une observation parallèle intéressante est qu'en java, "null" peut être implicitement typé. En effet, foo((String)null) et foo((Object)null) sont valides et permettent de sélectionner entre les deux méthodes foo :)
[^] # Re: Mes deux centimes ...
Posté par gc (site web personnel) . En réponse au journal Repenser les langages et le développement logiciel. Évalué à 4.
Pourquoi ?
Quand je me heurte concrètement à ce problème, les interfaces ne sont pas une solution pratique parce que je veux attacher des données ou du code en plus de l'API.
On s'est aussi rendu compte que la majorité des problèmes de l'héritage multiple sont dus à l'héritage multiple de structures (problèmes de l'héritage en diamant, p.ex.).
C'est a dire ? L'héritage en diamant me semble poser un problème dans l'implémentation du langage, pas pour le programmeur, je me trompe ?
On s'est aussi rendu compte que les autres cas d'héritage multiple sont relativement rares (comparativement aux ennuis) et facilement contournables par délégation.
D'une part je continue à penser que ça m'arrive bien plus souvent que le manque de multiméthodes, même si je suis d'accord que le besoin ne s'en fait pas sentir tous les jours[1]. D'autre part je continue à ne pas apprécier la délégation qui impose du code "dupliqué" au kilomètre.
tu fais plusieurs choix discutables, p.ex. que Laguna est une classe et que Renaut est une classe. Voiture est bien une classe, mais Renault est une instance de la classe Constructeur et Laguna une instance de la classe Modèle. Voiture aura donc deux attributs : constructeur et modèle.
C'est un exemple rapidement fait pour montrer qu'on peut avoir besoin de d'hériter de deux classes distinctes. D'ailleurs quelle est vraiment la différence ave le fait d'hériter d'une classe et d'implémenter une ou plusieurs interfaces ? Conceptuellement, on "suit", on "adhère" à différents "traits", "comportements", la seule différence est qu'on partage aussi des données ou du code dans un cas et pas dans l'autre. Je considère donc une interface comme une classe "réduite" mais je serais content qu'on me convainque du contraire ?
Je vais te donner un autre cas concrêt qu'il m'est arrivé, et dis-moi ce que tu penses de la conception.
Nous avons un ensemble de formes géométriques : Ligne, Rectangle, Polygone. On utilise une classe pour chacun, ce qui permet de stocker des données comme les deux points d'une Ligne ou les quatre points d'un Rectangle par exemple. On les manipule dans une application de calcul scientifique pour générer des espaces discrets.
D'autre part, nous avons un éditeur graphique pour dessiner des formes géométriques. Chaque forme géométrique devra donc implémenter certains comportements supplémentaires, comme se dessiner dans un espace graphique, mais elles ont aussi toutes en commun de posséder une couleur. Cette couleur est une donnée, et on veut rajouter des accesseurs pour la manipuler. On veut aussi rajouter du code (une méthode) pour marquer visuellement que cette forme est sélectionnée (la couleur passera à une couleur fixée, le gris en l'occurrence). Cela a été implémenté (en C++) par une classe mère GtkForme, chaque forme géométrique héritant ensuite de cette classe pour obtenir la couleur, et de sa classe de forme géométrique de base pour hériter de ses coordonnées.
Est-ce une mauvaise conception ? A cause du manque de l'héritage multiple, je ne sais pas comment faire ça élégamment en Java.
Alors tu me répondras : c'est de la délégation, c'est plus joli avec de l'héritage. Mais l'héritage n'a rien à voir dans ces relations. Le fait que tu puisses remplacer de l'utilisation (composition/aggrégation) par de l'héritage et que cela soit plus court à écrire n'est pas une raison pour le faire. Conceptuellement, ça ne tient pas.
Uniquement parce que dans mon exemple tu suggères de remplacer des classes par des instances ? Est-ce que tu peux m'expliquer pourquoi il est conceptuellement correct d'avoir un héritage simple et de l'implémentation d'interface(s), mais pas correct d'avoir un héritage multiple ? (en fait cette question se rapproche beaucoup de ma question du paragraphe précédent)
Enfin, pour mettre en perspective la pensée que l'héritage multiple est un symptôme de mauvaise conception, je citerais le fameux Craig R. McClanahan (monsieur struts, un des monsieur tomcat) dans la javadoc de org.apache.catalina.core.ApplicationHttpRequest (source de tomcat donc ) :
* WARNING: Due to Java's lack of support for multiple
* inheritance, all of the logic in ApplicationRequest is
* duplicated in ApplicationHttpRequest. Make sure that you
* keep these two classes in synchronization when making changes!
[1] je rapproche d'ailleurs ce problème du manque de destructeur dans les GC dits "modernes" ou "vrais" (java, ruby) avec mark & sweep, par rapport aux GC dits "faux" (perl, python) fonctionnant par compteur de référence ; concrètement il est assez rare d'avoir besoin de destructeurs vrais (c'est à dire qui sont vraiment appelés quand l'objet est déscopé), mais quand on en a besoin c'est très chiant de ne pas en avoir ; surtout utile pour les IOs, et les gens de jakarta-httpclient (pour java) sont obligés d'imposer un HttpMethod#releaseConnection bien crade et bien chiant à cause de ça.
[^] # Re: Mes deux centimes ...
Posté par gc (site web personnel) . En réponse au journal Repenser les langages et le développement logiciel. Évalué à 2.
En Java (je ne suis pas sur que tu parles de Java encore ou pas) je choisirais l'héritage multiple bien avant les multiméthodes. A cause du manque d'héritage multiple on se retrouve obligé de faire de la délégation kilométrique (ou pire). A mon avis ça manque bien plus.
D'ailleurs à propos du manque d'héritage multiple, je me heurte sans arrêt aux javaïens qui me disent qu'il faut « concevoir différemment » mais je cherche toujours une solution au problème simple suivant :
http://zarb.org/~gc/t/prog/lack_multiple_inheritance/(...)
[^] # Re: Sudo ou mettre l'utilisateur dans les bons groupes
Posté par gc (site web personnel) . En réponse au message Attribuer à un utilisateur le profil root. Évalué à 2.
tout utilisateur avec id 0 a le "profil" root, et rien n'empêche plusieurs utilisateurs d'avoir l'id 0 (édite ton /etc/passwd).
[^] # Re: Comme d'habitude....
Posté par gc (site web personnel) . En réponse au journal Repenser les langages et le développement logiciel. Évalué à 2.
Et ils ont raison, tu le démontres toi même :)
D'ailleurs faire des programmes prouvés c'est possible, c'est réalisé dans certains domaines critiques/importants. Et même par exemple dans les jeux vidéos pour console il y a très peu de bugs puisque l'éditeur sait très bien qu'il ne pourra pas patcher.
[^] # Re: Mes deux centimes ...
Posté par gc (site web personnel) . En réponse au journal Repenser les langages et le développement logiciel. Évalué à 2.
Je suis pas du tout convaincu. Dans la pratique c'est vachement rare de se faire flinguer par le manque de multiméthodes. Par exemple je vais du java au taf (ne moquez pas, ça me permet de me nourrir et de rester propre), c'est surtout le manque de sucre fonctionnel qui fait chier (et d'ailleurs le prochain C# en aura beaucoup apparemment), style map/grep, initialisation de listes statiques, fermetures. Après, ça dépend peut-être du type de programme et des connaissances ou du style du programmeur...
[^] # Re: rooh
Posté par gc (site web personnel) . En réponse à la dépêche La version 3 de Nessus sera propriétaire. Évalué à 2.
Je rappelle que « la société » ne demande pas au gestionnaire d'une entreprise d'adopter un point de vue moral ou social. On lui demande uniquement d'équilibrer ses comptes et d'avoir de bonnes perspectives d'avenir (accessoirement pour celles qui sont en Bourse, on leur demande 15% de taux de rentabilité).
NB : je ne décris pas ce que je veux/voudrais/aime/préfère, je décris la réalité.
Si l'optique de la contribution est l'amélioration du produit, c'est très criticable : ce n'est pas un ou quelques contributeurs isolés qui permettront à un projet d'une certaine envergure d'éviter de sombrer, si le reste du monde s'en désintéresse.
Personnellement j'ai contribué (petitement) à quelques projets libres dans le cadre de mon travail et ça ne change pas d'un iota les perspectives des projets (ni mes connaissances globales sur ces projets).
[^] # Re: C'est surtout le problème du logiciel libre.
Posté par gc (site web personnel) . En réponse à la dépêche La version 3 de Nessus sera propriétaire. Évalué à 6.
[^] # Re: c'est tjs le même problème...
Posté par gc (site web personnel) . En réponse à la dépêche La version 3 de Nessus sera propriétaire. Évalué à 2.
Je +++. J'habite en Suisse, sur leur interface de daube le premier truc à choisir c'est le pays de résidence. Une fois que j'ai choisi la Suisse, l'interface passe magiquement en Allemand (langue de la majorité des Suisses) et je n'y comprends plus rien. Bien sûr, aucune option, rien pour changer, même l'anglais à la limite, nada. J'ai envoyé un mail, j'ai reçu une réponse automatique navrante. J'ai du mal à filer mon numéro de carte de crédit en confiance sur une interface dont je ne comprends même pas ce que veut dire les boutons de confirmation ou d'annulation.
[^] # Re: licence adaptée à la fourniture de services, style GPLv3
Posté par gc (site web personnel) . En réponse à la dépêche La version 3 de Nessus sera propriétaire. Évalué à 3.
C'est pas vraiment ça qui est proposé. Ce qui est proposé, c'est que si le logiciel libre d'origine dispose d'une commande permettant aux « utilisateurs » du logiciel de télécharger le code source de ce logiciel, alors tout utilisateur, donc les boîtes aussi, doivent conserver cette commande. Et en plus, c'est encore à l'étude. Concrètement, il faut donc quand même que d'une part l'auteur du logiciel libre d'origine mette cette commande, et que cela s'y prète. Par exemple, pour le kernel je ne vois pas de moyen de le faire à moins de mettre un truc bien crade dans le kernel space. À mon avis, ce ne sera pas au point de rendre les business existants sur le libre (ce que fait google par exemple) bien plus difficiles (et heureusement) (enfin question de point de vue après tout).
Je cite RMS dans sa dernière interview :
We're looking at an approach where programs used in this way [NDM : comme « services »] will have to include a command for the user to download the source for the version that is running.
But this will not apply to all GPL-covered programs, only to programs that already contain such a command. Thus, this change would have no effect on existing software, but developers could activate it in the future.
This is only a tentative plan, because we have not finished studying the matter to be sure it will work.
If you release a program that implements such a command, GPL 3 will require others to keep the command working in their modified versions of the program.