Vous utilisez un autre langage que PHP. Pourquoi ?

[Anthor]

Code PHP :

<?php

class Item

{

    public $name;



    public function __Construct( $name )

    {

        $this->name = $name;

    }



    public function __toString()

    {

        return $this->name;

    }

}



class Character

{

    public $name;

    public $items = array();



    public function  __Construct( $name )

    {

        $this->name = $name;

    }



    public function __toString()

    {

        return $this->name;

    }

}

 

$corwin = new Character("Corwin");

$corwin->items[] = new Item("Grayswandir");



print $corwin . '\'s profile';

print '';

print 'Items (' . count($corwin->items) . ')';

foreach($corwin->items AS $item):

    print '  - ' . $item;

endforeach; 

[Zamentur]

Ben je vois pas trop de point à critiquer sur les 2 codes que tu as présentés...
Selon toi quel est l'avantage du code RoR par rapport au code PHP que tu as posté?

[Sephi-Chan]

Il s'agit de code Ruby. Rien n'est issu de Rails dans le snippet posté.

Il manque un peu d'encapsulation (attributs privés et accesseurs) au code proposé par Anthor (merci !), l'écriture des accesseurs est une tâche pénible et stérile (surtout quand ils ne font rien de particulier). En Ruby, on peut générer des accesseurs grâce aux méthodes attr_accessor (getter + setter), attr_reader (getter seul) et attr_writer (setter seul).

On peut tout de même voir que la syntaxe de Ruby permet de ne faire que l'essentiel. On ne se trimballe pas de $this->xxx partout (quand c'est nécessaire, on peut tout de même écrire self.xxx), on n'utilise pas nécessairement return (le dernier élément appelé est implicitement retourné, en Ruby).

La syntaxe est vraiment légère et douce à l'œil : pas de caractères visuellement bruyants à outrance ($ { } -> ; pour n'en citer que quelques uns).

C'est l'un des points très concrets qui fait qu'au final, Ruby est très agréable à écrire, à lire et à maintenir.

Si la facilité à lire est une question d'habitude, le ratio code écrit/code utile est intrinsèque au langage, et donc tout à fait objectif.


Sephi-Chan

[Anthor]

En fait pas besoin d'accesseur dans ce cas, si c'est pour remettre dans la variable uniquement, autant mettre la variable en public.
Je pense que c'est le code qui se rapproche le plus du tient du point de vue php, et dans le cas présent bien évidemment.

D'ailleurs en y pensant, je vois pas trop l'intérêt d'avoir des accesseurs uniquement pour passer une simple variable ?

[Sephi-Chan]

Si tu changes la politique d'accès de ton attribut, tu devras reprendre tout le code qui l'emploie. Ton code est plus robuste et maintenable avecun accesseur, aussi basique soit-il.


Sephi-Chan

[Anthor]

Si tu me montres le code avec un setter et un getter plus poussé en ruby, je veux bien voir ^^
Je pense pas que tu le feras en une ligne comme dans cet exemple.

A part modifier l'attribut, et ajouter les deux méthodes, le code est pas grandement changé ^^

[DragonMaster]

Le premier désavantage que je vois à Ruby est qu'il n'est pas dans la ligné syntaxique du C qui est le langage de référence de la majorité des cours d'informatiques un peu partout dans le monde. Ainsi, Ruby avec sa syntaxe (dévié de pascal, vb...?) est plus déroutant pour le programmeur. On pourrait maintenant débattre à savoir si la série des langages dévié du C ont une plus belles syntaxe ou non.

Quel est l'équivalent de public/private en Ruby?

Ruby ne serait-il pas un langage comme python qui force l'indentation correcte?

[Allwise]

Le petit confort d'avoir moins de caractères, de ne pas avoir le "this" qu'on retrouve dans d'autres langages, notamment C++, de ne pas écrire les getters et les setters, mais qu'on définit quand même un peu comme on définirait la portée d'une variable... Y a vraiment pas de quoi casser 3 pattes à un canard. C'est juste qu'on a tous les concepts de base et communs de programmation, et qu'on les écrit différemment. L'exemple n'était certainement pas le plus parlant m'enfin...
Mais je comprends que ça puisse être un vrai plus pour certains. Je comprends aussi que les lacunes de PHP qu'on retrouve pas chez Ruby, - je pense notamment au nommage bordélique des fonctions - ne peuvent faire de Ruby qu'un "meilleur" langage, et que chacun juge en fonction de ses propres critères. Pour ma part, c'est pas la façon d'écrire une méthode, une itération ou de déclarer une variable qui me donne mon opinion sur un langage. C'est de pouvoir le faire.
Par exemple un truc bien qui existe en Ruby et qui n'existe pas en PHP c'est la surcharge d'opérateurs.

[Ter Rowan]

au vu des deux codes, même si je sens un peu le paramatrage getter setter comme plus simple en ruby, je préfère le php/c++/java/c# etc..

je n'aime en effet pas du tout (mais c'est personnel) le côté pas de return, pas $this, etc...

enfin c'est personnel

---

Par exemple un truc bien qui existe en Ruby et qui n'existe pas en PHP c'est la surcharge d'opérateurs.

ah ben je croyais que ca existait en php tiens (bon je sais pas le faire mais ^^)

[Sephi-Chan]

Voici un setter un poil plus évolué (on met ce qu'on veut, hein) :

class Character

  attr_reader :name

  

  def name=(name)

    raise ArgumentError unless name.is_a?(String)

    @name = name

  end

end

Le premier désavantage que je vois à Ruby est qu'il n'est pas dans la ligné syntaxique du C qui est le langage de référence de la majorité des cours d'informatiques un peu partout dans le monde. Ainsi, Ruby avec sa syntaxe (dévié de pascal, vb...?) est plus déroutant pour le programmeur. On pourrait maintenant débattre à savoir si la série des langages dévié du C ont une plus belles syntaxe ou non.

Quel est l'équivalent de public/private en Ruby?

Ruby ne serait-il pas un langage comme python qui force l'indentation correcte?

Le fait que la syntaxe de Ruby ne soit pas héritée de celle du C est plutôt un bon point : c'est une syntaxe pleine de lourdeur. Les gens que j'ai pu initier à Ruby n'ont eu aucun problème avec ça. Ils ont vite pris goût à cette légèreté.

Les modificateurs de visibilité sont les mêmes (private, protected, public). On les applique un peu différemment.

class MyClass

  

  # Par défaut c'est publique.

  def my_method_1 

  end

  

  # On peut spécifier manuellement pour chaque méthode.

  def my_method_2

  end

  protected :my_method_2

  

  # Toutes les méthodes qui suivent ça sont privées.

  protected

  def my_method_3

  end

  

end

Et non, l'indentation n'a pas d'impact en Ruby.


Sephi-Chan