Compass : East Oriented

[srm]

Tout d'abord si tu pouvais faire des messages plus court ça m'arrangerait et inciterait plus de monde à participer iffle:

Ici aussi c'est le langage, PHP, qui t'interdit de travailler avec les private. Tell don't ask c'est bien mais je le redis : est-ce que chaque objet de ton système qui contient des données à afficher quelque part doit implémenter des putters ? Je trouve que le paradigme objet et surtout ses limites ne sont pas correctement définies par les langages qui les implémentent ; chaque semaine dans le monde de PHP on propose une nouvelle façon de faire de l'objet correctement.

Heu non c'est pas vraiment ça, "tell don't ask" c'est un vieux truc.
Et ça s'appel un pattern de conception et ce genre de pattern c'est utilisé depuis un moment dans le C, dans le Java et plein d'autres langages. PHP devenant de plus en plus sérieux et professionnel on voit donc ce type de pattern ramené à PHP pour le faire grandir et l'améliorer et ça de plus en plus souvent. Et ça n'est pas vraiment le langage qui limite mal, en fonctionnel aussi je peux te trouver plein de trucs crade et t'en faire si tu veux.

Concernant ton exemple de $a1 et $2, je ne saurais te dire si c'est une mauvaise implémentation ou pas, ça me semble être le cas. Un langage comme Scala par exemple ne fait pas ça, mais t'autorise cependant à faire un private sur le scope que tu veux, sur la classe, le package etc. Donc tu peux faire un private qui se comporte comme en PHP.

Ceci dit ton exemple ne peut pas se produite si on programme en East, car on demandera jamais à un objet sa variable

Concernant le côté overkill et l'exemple de putBalance, non c'est faux le solde de mon compte ne doit pas toujours être affiché avec un formatage. Si par exemple je dois l'afficher dans un export de données CSV, ça m'étonnerait que je mettes du formatage pour le solde de mon compte.

Tu peux très bien faire : <p><?php $account->putBalance(new HTML()) ?></p>
Concernant le fait qu'il y ai plus de classe : assurément, mais est-ce un mal ?
Concernant le fait qu'il y ai plus de ligne :
- mon ORM avant East : 612 lignes de code
- mon ORM en East : 663 lignes de code, seulement 50 lignes de plus alors que j'ai déjà ajouté plus de fonction, un système de Collection, un système de Query, entre autre.

Donc le code n'est pas plus long, et pas plus chiant à lire, par contre différent et nous impose une gymnastique à laquelle on est pas habitué.

De plus je viens de vérifier, tu es pas oblige de tout mettre des class partout pour faire de l'East, tu peux mettre des closures et utiliser des Interface et objet quand tu as besoin de plus de flexibilité (ORM avant East 15 fichiers, ORM avec East 16 fichiers)

En effet l'auteur pousse l'exemple du East jusqu'au boutisme je dirais.
Ce que je ne fais pas, tout en respectant les conventions East.

---

De toute façon les getter c'est clairement une aberration.
Avant :

class Bouh {

  public $name = 'Sylvain';

}



$bouh = new Bouh();

echo $bouh->name;

"Non c'est sale les propriétés de l'objet ne doivent pas être publique"

Maintenant :
Avant :

class Bouh {

  protected $name = 'Sylvain';

  public function getName() {

    return $this->name;

  }

}



$bouh = new Bouh();

echo $bouh->getName();

C'est sûr que du coup on a vachement progressé iffle: