0
Matz, le créateur de Ruby a annoncé la sortie de la version stable 1.8.5.
Ruby est un langage de programmation interprété orienté objet originellement développé au Japon. Il est souvent comparé à Python et à Perl bien qu'il utilise des concepts d'autres langages comme Smalltalk. L'application phare est actuellement le framework web Ruby on Rails.
Cette version est principalement une correction de bugs. En effet, le développement se concentre actuellement dans YARV (Yet Another Ruby VM) qui deviendra Ruby 2.0 à sa sortie, mais pas avant encore plusieurs mois. YARV est une réécriture de l'interpréteur (implémentation d'une machine virtuelle Just In Time et Ahead Of Time) qui tente d'apporter une solution au problème majeur de Ruby actuellement : ses performances.
![[en]](../images/en.png)
Ruby (398 hits)-
Documentation (159 hits)
-
L'annonce de la sortie (97 hits)
-
Récapitulation des changements (152 hits)
-
Changements dans la version de développement (1.9) (100 hits)
-
YARV (Futur Ruby 2.0) (398 hits)
> Lire les commentaires (44 commentaires, moyenne: 3,8).
Vous avez demandé le commentaire #748415.
Run by 
Cette page a été générée par Templeet en 0.1617s (dont 0.0216 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Problème majeur?
La dernière fois que je me suis mis à Ruby le problème majeur ce n'était pas les performances, mais surtout le manque de ressources à disposition (documentation, librairies...) à moins de maitriser le japonais. Je me souviens que mes recherches sur google ne menaient parfois à rien quand j'avais un problème, contrairement à Perl ou Python où on trouve toujours quelque chose. Mais ça s'est peut-être amélioré depuis, il faudrait que je regarde ça.
Sur le langage en lui-même y'a rien à dire, il est génial.
[^]Re: Problème majeur?
Jusqu'à présent, je lis la doc de l'API sur [url=http://www.ruby-doc.org/core] et je ne suis pas encore resté coincé avec une inconnue.
Peut-être employais-tu des parties spécifique, mais d'habitude, la doc voir même le code du module est facile à comprendre pour se débrouiller.
[^]Re: Problème majeur?
il y a aussi http://fr-draft.poignantguide.net/
La version brouillon de la traduction en français du Why’s (Poignant) Guide
[^]Re: Problème majeur?
Pour les librairies, il y a Ruby Forge (avec beaucoup de choses) :
http://rubyforge.org/
[^]Re: Problème majeur?
Sans oublier, en ligne de commande, ri ...
[^]Re: Problème majeur?
En attendant que la documentation revienne sur http://rubyfr.org tu peux consulter l'ancien wiki : http://rubyfr.pro1.typhon.org/rubyfr.org/
RubyFrance
[^]Re: Problème majeur?
Ça devait être il y a longtemps, car le livre "Programming Ruby" a été écrit par des gens qui se sont heurtés eux aussi au fait que la doc était en japonais, et il est paru en 2000. Je ne sais pas quand il a été libéré, mais ça fait quelques années déjà. C'est un très bon moyen de débuter Ruby.
Pour les bibliothèques, celle par défaut est pas mal fournie, et j'ai rarement eu de problèmes à trouver ce que je voulais dans Debian, ou sur le net en dernier recours ;) Je pense que ça s'est considérablement développé depuis que Ruby commence à être largement connu.
[^]Re: Problème majeur?
N'oublions pas non plus le non support de l'Unicode qui est vraiment un vrai problème et que de nombreuses librairies sont encore au stade de l'alpha / beta (je pense notamment au driver de PostgreSQL).
Concernant le langage en lui même, c'est mieux que du Perl, mais ça ne reste pas aussi lisible que du Python, et je trouve aussi dommage qu'ils aient repris certains trucs "sales" de Perl (notamment les variables "spéciales" $...) ...
[^]Re: Problème majeur?
Pour les regexpr en UTF-8 il suffit de rajouter l'option 'u' :
/../ === "é" -----> true
/../u === "é" -----> false
Par contre les $... sont plutôt un gros avantage : même principe que les pronoms, très utilisés dans toutes les langues, très utiles en Ruby par exemple avec les regexpr pour rappeler le texte trouvé.
[^]Re: Problème majeur?
Concernant le langage en lui même, c'est mieux que du Perl, mais ça ne reste pas aussi lisible que du Python
Ça c'est hyper dépendant de ton habitude et de tes préférences. Par exemple de mon point de vue, Ruby est plus lisible que Python.
[+] [^]Langage OO ?
Il y a enfin des destructeurs ???
Non ? Alors tant pis, je préfère en rester à des langages qui implémentent complètement le paradigme objet...
Berlin 1936, Moscou 1980, Pékin 2008.
Jeux Olympiques, sponsor officiel de la dictature.
Mexico 1968, Pékin 2008.
Jeux Olympiques, sponsor officiel de la répression.
[^]Re: Langage OO ?
Il n'y a pas de "destructeur" à la (C++/)Perl/Python puisque le GC ne fonctionne pas par compteur de référence comme chez eux mais par mark & sweep, et qu'il fait son ménage quand bon lui semble. En fait, a priori la littérature dit que Ruby implémente un "vrai" GC (comme Java par exemple), ce qui n'est pas le cas du compteur de référence de Perl/Python - et je dis ça en le déplorant profondément. Personnellement je préfère le comportement Perl/Python qui garantit un appel synchrone à un destructeur, cependant dans la pratique (en tous cas ma pratique assez poussée du java et du ruby) ça ne m'a jamais manqué.
Reste quand même qu'avec Ruby le finalizer est garanti de passer avant la fin du programme, ce qui n'est pas le cas dans la JVM.
http://zarb.org/~gc/t/prog/destructor/nodestructor.rb
[+] [^]Re: Langage OO ?
Je sais. La conclusion qui s'imposait était donc qu'un garbage collector (dans le cas de Perl et Python, comme tu le dis, ce ne sont pas de "vrais" GC) est totalement inadapté pour un langage orienté objet.
Question de style plus que de pratique poussée : moi, ça m'a manqué dès mon programme d'essai (un petit programme pour mouliner du XML simpliste et en sortir des pages HTML). J'en ai donc tiré la conclusion qui s'imposait et arrêté le Ruby avec résignation dans la foulée où je l'avais commencé avec enthousiasme.
Merci. Je ne me suis jamais mis au Java parce qu'il ne m'attire pas (il est loin d'avoir comme Ruby une certaine élégance conceptuelle qui suscite l'intérêt), que le peu que j'en ai vu m'a surtout donné l'impression qu'il impose pas mal de complications inutiles, et qu'il ne supporte pas vraiment l'héritage multiple.
Tu viens de me donner une bonne raison supplémentaire de ne jamais m'y mettre (jusqu'ici, celle-ci m'avait échappée).
Berlin 1936, Moscou 1980, Pékin 2008.
Jeux Olympiques, sponsor officiel de la dictature.
Mexico 1968, Pékin 2008.
Jeux Olympiques, sponsor officiel de la répression.
[^]Re: Langage OO ?
Le GC de Python fait aussi du mark and sweep. Depuis quelques années, même.
Par ailleurs, comme dans pas mal d'autres langages, rien ne garantit que ton "destructeur" va être appelé avant la fin du programme.
[^]Re: Langage OO ?
Vu que y'a 3066 Py_INCREF dans python 2.4.2 je pense que tu te goures.
[^]Re: Langage OO ?
J'ai dit « fait aussi du mark and sweep ». J'ai pas dit qu'il ne comptait plus les références.
[^]Re: Langage OO ?
Il n'y a pas de vrai ou de faux ramasse-miettes, il y a juste des façons de faire - le but étant de libérer la mémoire sans que le programmeur n'ait à s'en soucier.
Par ailleurs, dans Python il y a - en plus du comptage de références - un ramasse-miettes chargé de détecter les cycles et de détruire les objets devenus inutiles... mais encore référencés dans des structures cycliques.
(pub: Livres à prix réduit sur http://www.sollire.com/ - la boutique de mes petites soeurs)
[^]Re: Langage OO ?
Sans vouloir lancer un troll, je me demande : quels sont les intérêts indispensables d'un destructeur ?
Je ne le sais vraiment pas, n'ayant jamais codé en objet avec des destructeurs.
[^]Destructeurs
Rien n'est indispensable, on peut tout programmer en assembleur ou avec une machine de Turing. Après, il y a juste des trucs plus pratiques...
Concernant les desturcteurs en particulier, l'intérêt de base est de faire le nettoyage (notamment des ressources éventuellement allouées) ou la sauvegarde de l'état final à la fin de la vie de l'objet de manière automatique et transparente pour l'utilisateur de l'objet (qui n'est pas forcément la personne qui a programmé la classe).
SI tu programmes en style objet un peu extrême, le corps de ton appli consiste principalement en une suite de déclaration d'objets interdépendants, qui gèrent après leurs interactions entre eux, donc par conséquent, une bonne partie du code est localisé au niveau des constructeurs... et des destructeurs, encore faut-il qu'il y en ait.
Berlin 1936, Moscou 1980, Pékin 2008.
Jeux Olympiques, sponsor officiel de la dictature.
Mexico 1968, Pékin 2008.
Jeux Olympiques, sponsor officiel de la répression.
[^]Re: Destructeurs
Ceci dit, tu ne programmes pas de la même façon en C++ et en Ruby. Je ne sais pas ce que tu veux dire par 'implémenter complètement le paradigme objet', mais les destructeurs est un outil pour résoudre une classe de problemes, et Ruby propose un autre outil : les blocks.
L'exemple classique est le fichier que tu veux ouvrir et que tu dois fermer à la fin (dans le destructeur par exemple) :
File.open {|f|
# Faire des trucs avec f ...
}
à la fin de l'execution du block, le fichier est fermé.
Donc peut-être que tu as une approche qui n'est pas compatible avec la 'manière de faire' Ruby. Un peu comme si je me plaignais du manque des blocks en C++.
Par ailleurs, tu as un destructeur rudimentaire dans le module ObjectSpace (http://www.ruby-doc.org/core/classes/ObjectSpace.html )
Cependant, il est appelé 'après' la destruction de l'objet.
J'espere avoir ravivé ton interêt pour le Ruby :)
[^]Re: Destructeurs
En C++ et wxWidgets (C++ n'étant que le language, lui faut une bibliotheque, c'est aussi un avantage que je trouve au C++ : tu choisis ta bibliotheque!) :
{wxFile F(f);
// Faire des trucs avec f ...
}
à la fin de l'execution du block, le fichier est fermé.
Meme style de programmation, meme nombre de lignes, OK, ca me conforte, je n'ai toujours rien trouvé de mieux coté Ruby à part peut-etre une bibliotheque standart pas mal, mais bon, ré-inventer un n-ieme language pour une bibliotheque (comme Java d'ailleurs, qui n'est que du C++ castré pour pouvoir faire tourner un JVM, comme C# / J# / VB / etc...), ca devient gonflant... C'est plus un moyen de captation du marché, de verrouillage avec une bibliotheque précise, qu'autre chose...
Il y a des trucs plus propres qu'en C++ dans ces languages, mais de la à créer le buzz que c'est...
Il y a 3 ans, le buzz était au Python, il y a 2 ans le buzz etait sur .net (avec Mono), maintenant c'est Ruby, ces buzz ont des histoires courtes... On en parlera encore dans 5, 10 ans? quelle est la pérénité du code écrit?
Je vais jouer vieux con, je reste au C++, je peux encore utiliser avec lui du code écrit il y a 15 ans (et c'est souvent utile, il y a 15 ans des pregrammeurs n'étaient pas idiots...)
[^]Re: Destructeurs
En C++ et wxWidgets (C++ n'étant que le language, lui faut une bibliotheque, c'est aussi un avantage que je trouve au C++ : tu choisis ta bibliotheque!)
Tu peux également utiliser les fonctions de fichier proposés par la glib ou Qt via les binding Ruby.
Quant aux "histoires courtes" sur python, mono, ruby, ca tient du troll, sinon faut sortir de ta caverne.
RubyFrance
[^]Re: Destructeurs
> On en parlera encore dans 5, 10 ans? quelle est la pérénité du code écrit?
Bah, tu prend l'exemple de python ? la pérénité est assurée. Certaines distrib utilisent ça pour leurs outils, j'ai cru comprendre que pour websphere maintenant la console d'administration est en jython, on ne peut pas dire que ceux qui ont pris le train avec le buzz d'il y a 4 ans aient à le regretter.
Même chose pour .net, qui a des parts de marché énormes.
C'est sur que tu pourras tout faire en C++ (et même en basic à la limite), la question est juste de le faire plus simplement ou de manière plus agréable.
[^]Re: Destructeurs
>Même chose pour .net, qui a des parts de marché énormes.
Mouarf, dans les rêves de microsoft peut être....
.NET reste un gros bide pour l'instant.
[^]Re: Destructeurs
Huh ? Tu bases ton affirmation sur quoi ?
Faudra que j'en parle aux personnes que je connais et qui bossent sur de gros projets .Net...
[^]Re: Destructeurs
> Je vais jouer vieux con, je reste au C++, je peux encore utiliser avec lui du code écrit il y a 15 ans (et c'est souvent utile, il y a 15 ans des pregrammeurs n'étaient pas idiots...)
Mouais .. qu'on ne me parle pas de la lisibilité du code C++ écrit il y a 15 ans ... ni des pseudo-codeurs C++, qui font soit du C compilé avec g++, soit une demonstration de tous les design patterns (généralement 2) qu'ils connaissent ...
Pour ce qui est de la pérénité, de mémoire, la première version de Ruby date de 1995 ...
... ensuite tout est une histoire de gout ...
[^]Re: Destructeurs
Pour moi, les destructeurs font partie du paradigme objet.
Je sais, mais à ce stade-là, soit il faut systématiquement mettre l'utilisation de tous tes objets dans des blocs passés au constructeurs, ce que je trouve très moche (cela dit, c'est une question de goût), soit le jour où tu changes ton implémentation et où tu t'aperçois que tu as besoin de faire une finalisation, eh bien il faut modifier toutes les utilisations de ta classe.
C'est exactement ça. Donc j'en reste à un langage qui ne m'impose pas sa manière de faire.
Comme les finaliseurs, sur lesquels il se base certainement. Cela limite fortement l'intérêt : quand tu as quelque chose à faire en fin de vie d'un objet, c'est généralement dépendant des attributs de cet objet...
Eh non, désolé.
Berlin 1936, Moscou 1980, Pékin 2008.
Jeux Olympiques, sponsor officiel de la dictature.
Mexico 1968, Pékin 2008.
Jeux Olympiques, sponsor officiel de la répression.
[^]Re: Destructeurs
Pour moi, les destructeurs font partie du paradigme objet.
A ce niveau de non-justification c'est du troll. Il y a beaucoup de formalisations du "paradigme objet" différentes et elles se focalisent sur d'autres aspects plus fondamentaux (notion de méthodes ou bien de passage de message, héritage, etc.).
Mais bon, tu as le droit de dire que pour toi, les appuie-tête à motif léopard font partie du paradigme voiture.
Note que ta justification pour les destructeurs vient du fait que le langage implémente un système d'exceptions qui peuvent perturber le cours du programme à tout moment. Si le langage n'avait pas d'exceptions ou si leur implémentation était très différente, alors le besoin de finalisation automatique disparaîtrait. (mais peut-être que pour toi les exceptions aussi font partie du paradigme objet ;-)).
Je sais, mais à ce stade-là, soit il faut systématiquement mettre l'utilisation de tous tes objets dans des blocs passés au constructeurs
Là, ça tient de l'ignorance, puisque le système de blocs de ruby (de même que les fermetures en Python ou beaucoup d'autres langages) n'est pas limité à l'utilisation dans le cadre d'un constructeur. Dans l'exemple donné on devine bien que File.open est une banale méthode, pas un constructeur.
Du coup cela évite l'inconvénient du C++ où on doit créer de petits objets auxiliaires (des gardes, il me semble que c'est comme ça qu'on les appelle) gérant la finalisation d'une tâche menacée par des exceptions, parce qu'en C++ le seul moyen simple de faire de la finalisation est par le truchement d'un destructeur donc d'une désallocation d'un objet.
Plus fondamentalement cette utilisation de destructeurs pour la finalisation d'objet est assez criticable dans beaucoup de cas, car on ne voudra pas finaliser de la même façon selon qu'il y a eu une exception et que tout s'est bien passé. Par exemple, si je suis un serveur Web qui exécute un traitement CGI, je ne renverrai pas le même code de retour HTTP selon que le CGI termine bien ou qu'il me pète à la tronche. Donc les blocks try/except/finally sont souvent indispensables.
[^]Re: Destructeurs
Évidemment, mais si je programme déclaratif à fond, je n'ai pratiquement que des constructeurs dans les blocs de haut niveau, donc ça revient à ça.
Quoiqu'il en soit, ce n'est pas transparent à l'utilisation.
En même temps, vu qu'un destructeur est typiquement le truc qui ne rend rien, là il faudra bien utiliser explicitement autre chose pour avoir un code de retour (quitte pour moi à me résoudre à ne pas faire du 100% déclaratif ;-) ; de toute façon, à un certain niveau, il faut bien que je mette des instructions pour que mon programme fasse quelque chose)...
Berlin 1936, Moscou 1980, Pékin 2008.
Jeux Olympiques, sponsor officiel de la dictature.
Mexico 1968, Pékin 2008.
Jeux Olympiques, sponsor officiel de la répression.
[^]Re: Destructeurs
T'as pas des exemples ? Parce que dit comme ça ça me semble un peu étrange. En quoi l'essentiel des interraction entre objets se situe dans les constructeurs et destructeurs essentiellement ?
De mon point de vue, ce qu'il y a dans les constructeurs c'est des initialisations, des appels à d'autres constructeurs pour les compositions, mais les interractions elles se font essentiellement APRÈS la constrution de l'objet. Pour les destructeurs, je suis assez perplexe aussi.
[^]Re: Destructeurs
Le parallèle entre les constructeurs et les destructeurs est complétement mal venu. Le constructeur d'un objet est appelé à l'initiative de l'application, alors qu'en général on ne peut pas prévoir quand l'appel à un destructeur sera fait. Avoir une logique applicative dans un destructeur c'est un très mauvais design objet, il faut mieux avoir une méthode de finalisation appelée explicitement.
Tu parles en particulier de Python, alors qu'en Python l'utilisation des destructeurs est très découragée. D'abord parce que cela casse une partie du GC (en gros il a beaucoup de mal a détecter les cycles lorsque les objets définissent une méthode __del__). Ensuite parce qu'il y a (très) souvent moyen de faire mieux et plus propre. Un destructeur doit être utilisé dans des cas très particuliers.
[^]Re: Destructeurs
Ce point est TRES intéressant. J'ai justement eu un mini débat sur le sujet avec mes collègues : quel rôle donner aux constructeurs/destructeurs. En gros, jusqu'où va la construction de l'objet : simplement une affectation des membres à des valeurs par défaut pour rendre l'objet prèt à fonctionner ou du code réellement "fonctionnel".
Si vous avez des liens vers des "ouvrages" (au sens large, ce peut être un bouquin comme un wiki) sur le sujet, je suis vraiment intéressé.
Pour le coup, y'a vraiment un troll la-dedans, donc merci de resister à l'envie et poster uniquement des références.
[^]Re: Destructeurs
faut arreter de voir des trolls partout, il y a plusieurs façons de faire, et celle-là en est une bonne. parmi d'autres.
Windows has no users. It has hostages.
[^]Re: Destructeurs
J'ai lu cela justment il y a quelques jours.
http://today.java.net/pub/a/today/2006/08/24/five-habits-of-(...)
Toute une série de conseil, dont le premier est une réponse à ta question: "Constructor Performs Minimal Work"
Pour le détail de l'argumentation: "its constructor will only load data into its instance variables using the constructor's parameters."
"A constructor is used to create an instance of an object. A constructor's name is always the same as the object's name. Since a constructor's name is unchangeable, its name is unable to communicate the work it is performing. "
"the readability of the software is high because the constructor simply creates an instance of the object, letting the behavior and state-changing methods do the rest."
Voilou..
Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying
[^]Re: Destructeurs
C'est moins vrai dans le cas de langages qui autorisent plusieurs constructeurs de noms différents (pas le genre de truc qui me sert tous les jours, mais c'est vrai que quelquefois, c'est sympa)...
Berlin 1936, Moscou 1980, Pékin 2008.
Jeux Olympiques, sponsor officiel de la dictature.
Mexico 1968, Pékin 2008.
Jeux Olympiques, sponsor officiel de la répression.
[^]Re: Destructeurs
Tu ne confonds pas noms différents et signatures différentes ?
Dans ce cas la remarque reste valable.
[^]Re: Destructeurs
Là, tu penses probablement au C++.
Moi, je pense en particulier à Perl, où le constructeur est juste une méthode de classe qui a la particularité de retourner un nouvel objet de la classe. La convention suggère de l'appeler new, mais on peut aussi bien l'appeler zorglub ou en faire plusieurs.
Berlin 1936, Moscou 1980, Pékin 2008.
Jeux Olympiques, sponsor officiel de la dictature.
Mexico 1968, Pékin 2008.
Jeux Olympiques, sponsor officiel de la répression.
[^]Re: Destructeurs
Moi, je ne connais pas Perl, mais ce commentaire me fait penser à Objective-C. En effet, en Objc, il n'y a pas de constructeur à la C++/Java. La phase de construction est décomposée en deux :
- l'allocation : par appel d'une méthode de nom "alloc" sur la classe ;
- l'initialisation : par la méthode de nom recommandé "init" (mais on peut aussi l'appeler "zorglub") ou en créer plusieurs : initWithString, initWithDouble, initWithZorglub...
[^]Re: Langage OO ?
Note tout de même : le système de bloc retire une grosse partie de l'utilité des destructeurs. C'est la fin du bloc qui va libérer des ressources ou faire les finalisations nécessaires.
Sinon, sur le principe, les destructeurs existent, ils sont juste une galère à utiliser.