Frederick Ros a écrit 127 commentaires

L'avantage de passer par des methodes pour recuperer les valeurs (fes getters quoi) c'est de pouvoir facilement changer le type de ces valeurs.
Par exemple si l'envie me prend de changer la represenattion interne de la width au profit d'une table de hash (ca ne sert a rien just pour l'exemple), en faisant changeant juste l'implementation de ta methode width tu renvoie tj qq chose de coherent (une taille), alors que si tu n'as pas cette methode tu renverra la variable width .. qui est maintenant un hash.
Resultat: ca aura des effets de bors sur le code qui utilise ta classe... Il y a fort a parier que l'expression 5+ carre.width n'aura pas le meme comportement si width est un entier ou un hash ....

Dans le code expose en Ruby c'est fait par la ligne attr_reader :width, :height, qui cree 2 fonctions repondant au message width et height.

Du coup si tu as besoin de faire du refactoring de ta classe tu n'impact personne ....

Ce serait plutot des messages a la Smalltalk ... dont est fortement inspire Ruby.

"|".join( s.split(",") ) ## qui est même plus parlant qu'en ruby je trouve (*) ##

* : on voit bien que le retour de ça, sera du "string"

Super parlant en effet... Comme je l'ai dit dans un precedent commentaire, je comprends pas que l'operateur join appartienne a la classe String ...
En Ruby (je sais plus pour le Python), on parle de message, pas de methodes. Donc si je lis ton code avec un esprit de Rubyiste, je lis :

Envoie le message join a l'objet "l" ... Pas Zarb ca ?

Pour faire simple, en premier, je dirais que le mieux est d'essayer les deux et de garder celui qui te plait. J'ai essaye Python, il ne me convenait pas. Je n'aime pas le "delimitage" de blocs par des espaces, je n'aime pas a avoir a rajouter self au methode de ma classe, et je n'aimais pas les __ a tout va.
Les justifications de ces 2 problemes que j'ai trouvee ne m'ont pas convaincu du tout.
Ensuite tout est question de gout.

:TROLL ON: Rajoute a la va vite ? :TROLL OFF:
Je vois pas en quoi l'operateur join devrait s'appliquer a une chaine ...

Oui .. mais ecrire des livres est ce qui fait vivre Dave Thomas .. et vu le nombre de pages de la 2nde version il a du y mettre le temps ...

Tu peux aussi essayer : le Why (Poignant) Guide : http://poignantguide.net/ruby/(...) , pas encore complet mais ca avance ...

Tu as raison. Desole c'etait ma premiere news, je ferais mieux pour la seconde ;)

Effectivement la premiere version existe en HTML, et est meme downloadable (pour les utilisateurs de Gentoo elle se trouve meme dans Portage)
Pour la qualite du bouquin, ben quand on voit la qualite des autres livres de D. Thomas, on comprend ;)

Sur le site indique, dans la version papier ou PDF. Sinon sur Amazon ou le Monde En Tic

C'est marrant .. Je pense exactement l'inverse ... Je suis passe de XEmacs a Emacs il y a 3 ou 4 ans ... ca s'est fait sans douleurs, et je n'ai plus jamais relance un XEmacs depuis ...
Je reprochais a XEmacs d'etre plus lent a se lancer ou meme a highlighter le code ...

Merci.

Je ne sais pas si c'est exactement ce que tu veux, mais j'ai fait qq chose de similaire sur mon blog : http://sl33p3r.free.fr/blog/(...)

J'ai moi aussi qq chose du meme genre .. meme si c'est avec bogofilter.
Apres passage dans procmail, les "consideres comme spam" vont dans spam.detected.
De la je fais passer les vrais spam dans spam.kill et les faux dans spam.legit.
J'ai ensuite crone un petit script qui prend les mails de spam.kill et dit a bogofilter"oui, oui, c'est du spam", et les jettes, et qui prend les mails de spam.legit, les donne a bogofilter en lui disant "c'est pas du spam", et ensuite les deplace dans ma inbox ...
J'ai pique l'idee (et une premiere version du script) a _why ( http://whytheluckystiff.net/(...) ) (j'ai la flemme de chercher la page avec le script ..)

Tu peux aussi regarder ce thread: http://forums.gentoo.org/viewtopic.php?t=175883&highlight=dvora(...)

Bien que poste sur un forum Gentoo, il n'est pas specifique a cette distrib.

>apres, les gouts et les couleurs hein, chacun fait fait fait c'qu'il lui plait
> plait plait, mais qu'on vienne pas me dire qu'emacs n'est qu'un
> traitement de texte.

Arghh .. Emacs n'ext *pas* un traitement de texte. Emacs est un editeur de texte extensible .. Il s'appuie sur des outils exetrnes pour augmenter ses possibilite (pour les tags par exemple) .. Comme le fait vim et certains autres ...

> pitite question pour ma culture perso : est ce que la recherche de
> fonction etc.. est intelligente?
> je m'explique sous eclipse, quand tu cherche une methode, il te
> retourne uniquement celles qui correspondent a la signature (ie:
> typeRetour Classe.nomMethode(args) ), et pas celle qui
> correspondent juste au nom (ie: autreType
> AutreClasse.nomMethode(args)

Non .. mais ECB doit le faire. Il s'agit d'un package poru Emcas qui le transforme en "IDE" .. Il est apparamment vraiment pas mal pour peu que l'on fasse du C/C++ ou du Java. On peut bien sur lui ajouter de nouveau langage mais il faut alors s'investir un peu ...

> C++ est l'un des premiers langages objets, c'est pour ca que maintenant on en a fait de meilleurs (en tout cas différents)

Euh .. je veux pas etre medisant mais AFAIR C++ ca date du debut des annees 80 (80/83 si je me trompe pas) ... Smalltalk c'est quant meme 1972 ... et c'est vraiment de l'objet ...

> Quand aux mutex, c'est dommage maintenant qu'ils sont quasiment
> cablés dans le processeurs. Alors parler d'overhead des mutex, j'y
> crois pas trop en fait. Pour la complexité, je dis pas, mais pour
> l'overhead...

Ben IMHO, sur systeme SMP, il y a overhead .. S'il faut invalider les zones memoires correspondantes, il va bien falloir que ca parte sur le bus ..etc....

Mais je pense que le plus gros pb est effectivement la complexite resultante .. Passe encore quand le lock/release se fait dans ta fonction, mais si si lock dans une fonction, passe le lock a une autre (qui le passera peut-etre a une autre ...) , ben pour retrouver ses petits ca doit pas etre triste ....

Franchement pas beaucoup .. Quand je code en Perl, Ruby ou Lisp, mais bugs sont tres rarement dus a un probleme de typage ...

Oui .. suite a un appel d'offre du DoD :)

Humm ... Pas d'accord....
Lisp est un tres bon lanage pour apprendre a programmer ... et on peut pas dire qu'il ait un typage fort ...
Certains pensent meme (et j'en suis) que l'assembleur (OK, un vrai, pas du x86 ;) est meme tres bien pour ca: http://savannah.nongnu.org/projects/pgubook(...)

Pour en revenir a Ada, j'ai eu a l'apprendre moi aussi .. et j'ai meme eu a le pratiquer dan smon environnement professionnel ... et c'etait pas triste: probleme de compilos et outils (on a meme du demander a ACT de le porter, sur Winblows la version utiliser n'avait qu'un debugger approximatif et necessitait de debugger en assembleur), probleme de "mixage" avec d'autres langages (en gros: un thread executait une fonction C++, qui appelait du code ADA, qui lancait des timers (ecrits en C++), appelant une fonction ADA a leurs reveil ...
Le gros pb qui a conduit a l'elimination progressive d'ADA etait surtout un pb de resources: il devenait dur de trouver des devs qui voulaient faire de l'Ada :(

Oui .. enfin ca si je me rappelle bien c'est un peu un mythe urbain ...
L'histoire qu'on m'avait compte etait un peu differente:
Le DoD d'apercevant en 1975/76 qu'un peu plus de 450 langages etaient utilises pour les programmes du gouvernement et que cela coutait bcp d'argent en entretien/formation/..etc.. decida de lancer la creation d'un langage de haut niveau, permettant d'ecrire un code sur leauel on pouvait compter...etc...

Hummm .. je prefere Ruvi (http://www.lypanov.net/xml/development/ruvi.xml(...)) ;)

Hummm .. je prefere Ruvi (http://www.lypanov.net/xml/development/ruvi.xml(...)) ;)

AFAIK, KDE et GNOME ne sont pas des WMs
Pour ce qui est des forks, il suffit de regarder les blackbox/fluxbox/openbox/whitebox .. et consorts ....

Bon, c'est quand meme pas vraiment nouveau .. Ca date de debut avril non ?
Pour ce qui est de kahakai, ce qui est quand meme sympa, c'etait son but: etre scriptable dans plusieurs langage.. certes seul python et ruby etaient developpes dans ces versions mais quand meme ... ca permettait d'obtenir de petits trucs sympas ...

Pour ce qui est de aegis: un coup d'oeil regulier sur les screenshots permet de voir que ca avance:

http://aegis.thegraveyard.org/index.php?module=photoalbum&PHPWS(...)