Re: ruby et genie logiciel

Je ne vois dans le duck typing qu'une manière de présenter le typage
dynamique... Je me trompe peut-être, mais alors j'aimerais bien
connaître la différence.

> J'adore cette phrase. Surtout dans le contexte
>    puts "3" + 1  qui oblige à ajouter un appel
>    puts "3" + 1.to_s
Est-ce ironique ?
Quoi qu'il en soit je trouve un grand intérêt à cette obligation :
aucun transformation ne se passe dans notre dos, on sait ce qu'on a.
De plus rien n'empêche de faire une méthode qui ajoute le to_s (ou un
to_i) automatiquement ("3".to_s marche très bien).


> J'adore aussi (apres avoir bouffer quelques mois de PHP) que
> l'équivalent true obtenu
> soit par les valeur "false",  "0", "", 0,  0.0,  "C'est pas vrai"
> Php, tres évolué, interprète les chaines précédentes comme étant
> false !!
Là encore je ne sais pas où es l'ironie :p
J'ai vu ça comme une libération, de ne pas avoir à tester (str || str
== '')
D'ailleurs en général il me fallait un peu de temps et de tests pour
trouver que c'était ma chaîne qui était bien là mais vide...

Ces 2 points se complètent : Ruby ne se permet pas certaines choses,
ce qui rend le code plus intuitif et plus propre.


On 22 jan, 09:25, mdiam <Maurice.Diamant...@gmail.com> wrote:
> On 17 jan, 16:37, doh...@gmail.com wrote:
>
> Merci Etienne pour tes informations.
> Ce serait bien que ces informations soient disponibles facilement
> quand on se
> pose ce genre de question (e.g. sur un wiki fr par exemple ?)
>
> Par ailleurs, je suis tombé sur la page "http://fr.wikipedia.org/wiki/
> Programmation_orientée_objet"
> Et concernant le typage ils distinguent :
>
> > On distingue dans les langages objets trois mécanismes du typage :
> > - le typage dynamique : ...  (Smalltalk, CLOS, Piquet, PHP...),
> > - le typage statique : ...  (C++, Java, C#, Pascal...),
> > - le typage par inférence : ...(C#, OCaml).
>
> Sans mention de Ruby nul part ni du typage canard.
>
> Est-ce que quelqu'un peut rajouter le typage canard, avec une ou deux
> ligne pour
> mentionner Ruby sans dire de bétises ??
>
> > Je tiens à préciser que le typage du Ruby est dynamique mais fort. Par
> > exemple "3" + 1 ne marchera pas.
>
> J'adore cette phrase. Surtout dans le contexte
>     puts "3" + 1  qui oblige à ajouter un appel
>     puts "3" + 1.to_s
> On apprécie de ne pas pouvoir faire
>     puts "3" + to_s(1)
>
> J'adore aussi (apres avoir bouffer quelques mois de PHP) que
> l'équivalent true obtenu
> soit par les valeur "false",  "0", "", 0,  0.0,  "C'est pas vrai"
> Php, tres évolué, interprète les chaines précédentes comme étant
> false !!
> (hum, peut-etre pas la toute dernière, mais c'est surement prévue pour
> php7 : il
> faut bien que ce langage évolue ;-)
>
>
>
> > > Le typage dynamique permet de coder rapidement et d'avoir du code
> > lisible (pas de casts ni de généricité), le développeur peu ainsi
> > prendre du temps pour "penser". La gestion automatisée de la mémoire
> > remplie la même fonction.
> > Je retiens 2 choses importante sur le typage dynamique :
> > - le code est plus simple, plus lisible, on ne s'ennuie pas avec plein
> > de détails, on ne créé pas des interfaces par centaines,  etc
> > - les erreurs sont signalés à l'exécution uniquement, les fautes de
> > frappe font plus mal (mais c'est aussi pour cela que les tests
> > unitaires existent)
>
> > Parlons des fonction. Il n'y a que des objets en Ruby, pas de type
> > primitif... et pas de fonctions. "+" est donc une méthode, que l'on
> > peut appliquer à un entier comme à une chaîne de caractère. Il n'y a
> > donc pas de surcharge d'opérateur. De plus le Ruby permet d'attribuer
> > simplement un nombre de paramètre variable, ou de donner une valeur
> > par défaut à un paramètre. Si l'on déclare 2 fois une méthode, la
> > deuxième déclaration écrasera la première. On évite ainsi les prises
> > de tête que procure C++.
>
> > Le côté "tout ouvert" de Ruby perturbe au début, et parait peu
> > crédible. Par côté tout ouvert j'entends l'introspection poussée et le
> > fait qu'on puisse ajouter dynamiquement des fonctionnalités à une
> > classe (ou directement à un objet).
> > Mais si l'on oublie l'aspect sécurité ($SAFE est là pour ça) il se
> > révèle très pratique, et permet de faire des choses surprenantes. Un
> > bon exemple est l'ActiveRecord::Base qui crée dynamiquement (peut-être
> > même aussi virtuellement, se contentant de faire "comme si" les
> > méthodes existaient) une classe en fonction des champs d'une table
> > d'une base de donnée.
> > Il permet entre autre de remplacer efficacement certains patrons de
> > conceptions (qui servent à contrer certaines barrières du langage) et
> > favorise la création/utilisation de framework. Bref, avantage notable.
>
> > Un mécanisme très intéressant du Ruby (tiré du Smalltalk si je
> > m'abuse) est le mixin. Il permet de remplacer l'héritage multiple en
> > le simplifiant. Une classe ne peut hériter que d'une et une seule
> > classe, mais inclue autant de module qu'elle le souhaite. Un module ne
> > peut hériter de personne mais peut inclure d'autres modules. Au lieu
> > de donner des signatures de méthodes (interfaces), on fournit
> > directement leur implémentation. Un exemple de module est Singleton,
> > qui transforme notre classe en singleton.
>
> > OUTILS
>
> > Je n'ai pas vraiment fait le tour des outils faits en ruby, mais je
> > peux au moins en citer 3.
>
> > Rake est un remplacement de make/ant. Le fichier de configuration est
> > écrit directement en Ruby.
>
> > RUnit est un framework de tests unitaires (pas encore testé, mea
> > culpa, mais visiblement très proche de JUnit)
>
> > ruby-debug fait comme son nom l'indique (mais ne devrais bien sur
> > jamais avoir à servir :p)
>
> > CONCLUSION
>
> > C'est surtout une question de goût. Le Ruby offre un bon nombre de
> > simplifications et de raccourcis en tentant de rester simple à
> > appréhender.
> > Certains y préférerons un langage plus sévère, guidant (bridant ?)
> > plus le développeur.
> > Personnellement je pense qu'un concept primordial du génie logiciel
> > est "penser", et le fait de pouvoir coder vite permet de penser plus,
> > et d'avoir moins peur des changements.
>
> > On 15 jan, 20:30, Jack <jack.c...@caramail.com> wrote:
>
> > > bonjour,
>
> > > j'essaie de regrouper des informations sur la pertinence d'employer Ruby
> > > pour concevoir des logiciels en suivant les principes du génie logiciel
>
> > > par exemple sur les avantages que ce langage procure dans cet usage, et
> > > sur l'éventail des outils qui existent pour ce langage à cet usage,
> > > genre qualité, documentation, tests, etc...
>
> > > par exemple est ce que le coté interprété du langage, le typage non
> > > strict, les mécanismes automatisés de gestion de la mémoire, sont un
> > > avantage pour faire du génie logiciel ?
>
> > > bref voila, tout ce qui vous semble être un atout (ou au contraire une
> > > faiblesse) du langage Ruby pour faire face à ces contraintes.
>
> > > (désolé je ne cross poste pas mais je fais un panel de ce qui existe en
> > > génie logiciel pour tous les langages interprétés en fait, donc je poste
> > > aussi pour Python, Perl, et PHP)
>
> Excellent, j'espère aussi que ce panel sera accessible !
> -- Maurice Diamantini