samedi 06 février

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Développeur

Liens connexes

Ruby (404 clics)
Documentation (165 clics)
L'annonce de la sortie (102 clics)
Récapitulation des changements (156 clics)
Changements dans la version de développement (1.9) (106 clics)
YARV (Futur Ruby 2.0) (404 clics)

Dépêche modérée par

mouns

Dépêche éditée par

Développeur : Sortie de Ruby 1.8.5

Posté par Hank Lords (Jabber id, ). Modéré le 25 août 2006.

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.

Ruby (404 clics)
Documentation (165 clics)
L'annonce de la sortie (102 clics)
Récapitulation des changements (156 clics)
Changements dans la version de développement (1.9) (106 clics)
YARV (Futur Ruby 2.0) (404 clics)

> Lire les commentaires (44 commentaires, moyenne: 3,8).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

...

Posté par Slainer (Jabber id, page perso, ) le 25/08/2006 à 14:36. (lien). Évalué à 10.

J'avoue que j'ai découvert Ruby grâce à Ruby on Rails, le framework dont tout le monde parle (mais y a une raison à cela, je vous laisse le soin de lire le livre Agile Web Development with Rails, qu'il est impossible de lire entièrement sans pousser des : "oh!", "wahou!", tellement certains concepts sont bien pensés)...

J'apprécie ce langage objet clair à lire, cela fait bizarre, mais c'est marrant de pouvoir mettre dans son code Rails des 15.minutes.ago pour afficher l'heure d'il y a 15 minutes ou des 15.times plutot que des for(truc = 1; i<=15; i++) et j'en passe.

Ruby et Ruby on Rails m'ont définitivement incités à me relancer dans le développement Web après quelques années de PHP qui ont finies par légèrement me saouler...

[^]Re: ...

Posté par EppO (page perso, ) le 25/08/2006 à 15:41. (lien). Évalué à 5.
Je me suis fait _exactement_ la même réflexion. On peut lire son code (presque) comme on lirait son commentaire.

Ruby est vraiment un langage séduisant de part sa facilité de prise en main et son efficacité tranchante dans le cadre d'un framework comme RoR.

Je m'étais penché à recoder un site communautaire en PHP5 et avait fait le proof of concept. Après avoir découvert RoR, quelques tutos et coder quelques exemples, quand j'ai revu mon code PHP5 ensuite, ca m'a piqué les yeux :)

La rapidité de developpement, la maintenance du code, et plein de ptits détails (migration, console irb, ...) couplé à un IDE comme TextMate, le développement web redevient un réel plaisir ! (ca ferait un bon spot de pub geekesque)

[^]Re: ...

Posté par Frederick Ros (page perso, ) le 27/08/2006 à 12:21. (lien). Évalué à 2.
> 15.times plutot que des for(truc = 1; i<=15; i++) et j'en passe.

Tu peux tj faire un (1..15).each {|i| ... } si vraiment tu en as envie ;)

Problème majeur?

Posté par Darkael () le 25/08/2006 à 16:31. (lien). Évalué à 3.

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?

Posté par Stephane Wirtel () le 25/08/2006 à 16:47. (lien). Évalué à 2.
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?
  
  Posté par baud123 (Jabber id, page perso, ) le 25/08/2006 à 17:26. (lien). Évalué à 3.
  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?
  
  Posté par Frédéric COIFFIER (Jabber id, ) le 25/08/2006 à 21:01. (lien). Évalué à 3.
  Pour les librairies, il y a Ruby Forge (avec beaucoup de choses) :
  
  http://rubyforge.org/
- [^]Re: Problème majeur?
  
  Posté par Frederick Ros (page perso, ) le 27/08/2006 à 12:22. (lien). Évalué à 2.
  Sans oublier, en ligne de commande, ri ...

[^]Re: Problème majeur?

Posté par fredix (Jabber id, page perso, ) le 25/08/2006 à 21:38. (lien). Évalué à 4.
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?

Posté par Yusei () le 26/08/2006 à 10:25. (lien). Évalué à 6.

La dernière fois que je me suis mis à Ruby l problème majeur ce n'était pas les performances, mais surtout le manque de ressources à disposition (documentation, librairies...) à moins de maitriser le japonais.

Ç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?

Posté par Julien (page perso, ) le 26/08/2006 à 11:38. (lien). Évalué à 4.
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?
  
  Posté par espace () le 26/08/2006 à 14:09. (lien). Évalué à 2.
  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?
  
  Posté par gc (page perso, ) le 26/08/2006 à 18:04. (lien). Évalué à 10.
  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 ?

Posté par Arthur Accroc () le 26/08/2006 à 16:14. (lien). Évalué à -2.

Sur le langage en lui-même y'a rien à dire

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...

--
« L'Homme n'est pas une marchandise comme les autres. » Nicolas S. (esclavagiste ?)
- [^]Re: Langage OO ?
  
  Posté par gc (page perso, ) le 26/08/2006 à 18:02. (lien). Évalué à 6.
  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 ?
    
    Posté par Arthur Accroc () le 27/08/2006 à 00:26. (lien). Évalué à -1.
    
    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.
    
    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.
    
    cependant dans la pratique (en tous cas ma pratique assez poussée du java et du ruby) ça ne m'a jamais manqué.
    
    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.
    
    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.
    
    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).
    
    --
    « L'Homme n'est pas une marchandise comme les autres. » Nicolas S. (esclavagiste ?)
  - [^]Re: Langage OO ?
    
    Posté par Boa Treize (page perso, ) le 30/08/2006 à 03:22. (lien). Évalué à 3.
    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 ?
      
      Posté par gc (page perso, ) le 30/08/2006 à 07:56. (lien). Évalué à 3.
      Vu que y'a 3066 Py_INCREF dans python 2.4.2 je pense que tu te goures.
      - [^]Re: Langage OO ?
        
        Posté par Boa Treize (page perso, ) le 31/08/2006 à 06:06. (lien). Évalué à 2.
        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 ?
    
    Posté par Laurent Pointal (page perso, ) le 30/08/2006 à 08:06. (lien). Évalué à 4.
    
    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
    
    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 ?
  
  Posté par Maz (page perso, ) le 26/08/2006 à 20:18. (lien). Évalué à 2.
  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
    
    Posté par Arthur Accroc () le 26/08/2006 à 23:55. (lien). Évalué à 5.
    
    Sans vouloir lancer un troll, je me demande : quels sont les intérêts indispensables d'un destructeur ?
    
    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.
    
    --
    « L'Homme n'est pas une marchandise comme les autres. » Nicolas S. (esclavagiste ?)
    - [^]Re: Destructeurs
      
      Posté par Hank Lords (Jabber id, ) le 27/08/2006 à 07:51. (lien). Évalué à 7.
      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
        
        Posté par Zenitram (page perso, ) le 27/08/2006 à 09:41. (lien). Évalué à 1.
        
        File.open {|f|
        # Faire des trucs avec f ...
        }
        
        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
        
        Posté par fredix (Jabber id, page perso, ) le 27/08/2006 à 10:24. (lien). Évalué à 6.
        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
        
        Posté par Éric (Jabber id, page perso, ) le 27/08/2006 à 10:40. (lien). Évalué à 8.
        > 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
        
        Posté par oops (page perso, ) le 27/08/2006 à 12:24. (lien). Évalué à 2.
        >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
        
        Posté par Boa Treize (page perso, ) le 30/08/2006 à 03:26. (lien). Évalué à 3.
        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
        
        Posté par Frederick Ros (page perso, ) le 27/08/2006 à 11:51. (lien). Évalué à 10.
        > 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
        
        Posté par Arthur Accroc () le 28/08/2006 à 18:11. (lien). Évalué à 0.
        
        Je ne sais pas ce que tu veux dire par 'implémenter complètement le paradigme objet'
        
        Pour moi, les destructeurs font partie du paradigme objet.
        
        File.open {|f|
        # Faire des trucs avec f ...
        }
        
        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.
        
        Donc peut-être que tu as une approche qui n'est pas compatible avec la 'manière de faire' Ruby.
        
        C'est exactement ça. Donc j'en reste à un langage qui ne m'impose pas sa manière de faire.
        
        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.
        
        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...
        
        J'espere avoir ravivé ton interêt pour le Ruby :)
        
        Eh non, désolé.
        
        --
        « L'Homme n'est pas une marchandise comme les autres. » Nicolas S. (esclavagiste ?)
        
        [^]Re: Destructeurs
        
        Posté par Antoine () le 28/08/2006 à 19:28. (lien). Évalué à 6.
        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
        
        Posté par Arthur Accroc () le 28/08/2006 à 20:37. (lien). Évalué à 1.
        
        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.
        
        É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.
        
        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.
        
        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)...
        
        --
        « L'Homme n'est pas une marchandise comme les autres. » Nicolas S. (esclavagiste ?)
    - [^]Re: Destructeurs
      
      Posté par Thomas Douillard () le 27/08/2006 à 10:14. (lien). Évalué à 8.
      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
      
      Posté par Thomas Hervé () le 27/08/2006 à 17:20. (lien). Évalué à 6.
      
      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.
      
      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
      
      Posté par Bonnefille Guilhem (page perso, ) le 28/08/2006 à 08:29. (lien). Évalué à 6.
      
      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.
      
      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
        
        Posté par Gniarf () le 28/08/2006 à 14:37. (lien). Évalué à 1.
        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.
        
        --
        "Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008
      - [^]Re: Destructeurs
        
        Posté par Gabriel () le 29/08/2006 à 21:05. (lien). Évalué à 3.
        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
        
        Posté par Arthur Accroc () le 30/08/2006 à 07:49. (lien). Évalué à 1.
        
        "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. "
        
        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)...
        
        --
        « L'Homme n'est pas une marchandise comme les autres. » Nicolas S. (esclavagiste ?)
        
        [^]Re: Destructeurs
        
        Posté par golum () le 30/08/2006 à 18:43. (lien). Évalué à 4.
        Tu ne confonds pas noms différents et signatures différentes ?
        Dans ce cas la remarque reste valable.
        
        [^]Re: Destructeurs
        
        Posté par Arthur Accroc () le 30/08/2006 à 20:49. (lien). Évalué à 1.
        
        Tu ne confonds pas noms différents et signatures différentes ?
        
        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.
        
        --
        « L'Homme n'est pas une marchandise comme les autres. » Nicolas S. (esclavagiste ?)
        
        [^]Re: Destructeurs
        
        Posté par Bonnefille Guilhem (page perso, ) le 31/08/2006 à 12:03. (lien). Évalué à 2.
        
        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.
        
        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 ?
  
  Posté par Éric (Jabber id, page perso, ) le 27/08/2006 à 10:40. (lien). Évalué à 3.
  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.

Apprentissage de Ruby

Posté par Stephane Wirtel () le 25/08/2006 à 16:32. (lien). Évalué à 7.

J'ai appris Ruby avec un ami, a l'époque je n'aimais pas trop les langages de scripts tels que Python ou Perl, car je préférais du code compilé à du code interprété. Je préférais donc coder en C/C++.

Par après, j'ai appris à employer Ruby dans les bons moments, là où c'est vraiment utile, génération automatique de code, création aisée de fichier XML etc.... enfin des choses qui prennent bcp plus de temps à réaliser en C++.

Depuis lors, j'ai regardé RoR et honnêtement, j'ai été sur le Q de voir tout ce qu'il était possible de faire en très peu de temps. Bien que j'ai déjà eu des connaissances en PHP (3 & 4), l'utilisation de l'ActiveRecord et des autres composants de Rails donne des avantages indégniable par rapport à d'autres outils.

Honnêtement, j'attends avec impatience la fameuse version 2.0 de ruby qui devrait permettre l'utilisation d'une autre VM, car l'actuelle est effectivement très lente.

Pour rappel, il existe de très bons ouvrages sur Ruby et RoR, ainsi que RadRails et RDT qui s'utilisent avec Eclipse.

[^]Re: Apprentissage de Ruby

Posté par Maz (page perso, ) le 26/08/2006 à 20:16. (lien). Évalué à 4.

Honnêtement, j'attends avec impatience la fameuse version 2.0 de ruby qui devrait permettre l'utilisation d'une autre VM, car l'actuelle est effectivement très lente.

Surtout, il n'y en a pas, actuellement :).

Revenir en haut de page

Articles précédents : Développeur

Liens connexes

Dépêche modérée par

Dépêche éditée par

Développeur : Sortie de Ruby 1.8.5

...

[^]Re: ...

[^]Re: ...

Problème majeur?

[^]Re: Problème majeur?

[^]Re: Problème majeur?

[^]Re: Problème majeur?

[^]Re: Problème majeur?

[^]Re: Problème majeur?

[^]Re: Problème majeur?

[^]Re: Problème majeur?

[^]Re: Problème majeur?

[^]Re: Problème majeur?

[+] [^]Langage OO ?

[^]Re: Langage OO ?

[+] [^]Re: Langage OO ?

[^]Re: Langage OO ?

[^]Re: Langage OO ?

[^]Re: Langage OO ?

[^]Re: Langage OO ?

[^]Re: Langage OO ?

[^]Destructeurs

[^]Re: Destructeurs

[^]Re: Destructeurs

[^]Re: Destructeurs

[^]Re: Destructeurs

[^]Re: Destructeurs

[^]Re: Destructeurs

[^]Re: Destructeurs

[^]Re: Destructeurs

[^]Re: Destructeurs

[^]Re: Destructeurs

[^]Re: Destructeurs

[^]Re: Destructeurs

[^]Re: Destructeurs

[^]Re: Destructeurs

[^]Re: Destructeurs

[^]Re: Destructeurs

[^]Re: Destructeurs

[^]Re: Destructeurs

[^]Re: Destructeurs

[^]Re: Langage OO ?

Apprentissage de Ruby

[^]Re: Apprentissage de Ruby