JeuWeb - Crée ton jeu par navigateur
Compass : East Oriented - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Compass : East Oriented (/showthread.php?tid=7165)

Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30


RE: Compass : East Oriented - niahoo - 10-08-2014

Tiens ben du coup chaque objet suscetible d'avoir une valeur envoyée a un flux va implementer une methode qui écrit sur un flux, et ce pour chaque variable (put ceci, put cela). Alors qu'on aura quand meme *tres probablement* des getters ... quelle bonne idée

Voilà, post un peu confus désolé c'est les vacances. Pour essayer de donner le bon angle de lecture à mon post je tiens à rappeller que j'aime bien PHP, d'autant plus que je l'ai dénigré les dernières années. Mais maintenant je sais ce qu'il vaut, je sais m'en servir (edit: plus ou moins Wink ) donc c'est un langage qui m'est utile et qui me plait. Ce post n'est pas là pour descendre php, bien que je puisse parler de ses faiblesses :

(10-08-2014, 01:13 PM)Sephi-Chan a écrit :
(10-08-2014, 01:12 PM)niahoo a écrit : (Suite de mon post) Je vais dire un truc un peu pédant mais depuis que je fais du FP et de l'objet en erlang, ma façon de coder objet en php s'est nettement éloignée de ce genre de considerations sur la syntaxe ou la façon d'ecrire.

C'est à dire ?
FP pour functional programming je suppose ?

Functional programming oui. C'est un paradigme simple, et les langages FP renforcent ce paradigme. En objet chaque développeur va avoir sa définition de l'OOP ...

En PHP tu n'as pas d'envoi de message. Tu peux appeler une méthode et dire à tes élèves "là, j'envoie un message" mais c'est des conneries. Tu appelles simplement une fonction avec certains paramètres dont un paramètre caché, $this. D'ailleurs, si tu regardes comment on implémente une classe en Lua (edit: sans les metatables, avec self, ce qui d'ailleurs n'est pas la manière la plus performante ni la plus fun) tu vois exactement ce mécanisme.

En PHP tu n'as pas de vraie isolation au sein d'une classe. Tu peux toujours taper sur des globales, tu dois déclarer des public/protected/private ou alors des getters idiots* qui renvoient bêtement une variable protected (*idiots mais nécessaires puisqu'on les définit comme envoi de message). De plus la portée est définie par la classe, ce qui donne la possibilité de faire ça :
<?php

class A {
private $v;

public function __construct($v) {
$this->v = $v;
}

public function foo (A $a) {
echo $a->v , "\n";
}
}

class B extends A {

}

$a1 = new A(1);
$a2 = new A(2);
$a1->foo($a2); // 2
$b = new B(3);
$b->foo($a2); // 2


Je ne dis pas que c'est mal, j'ai du m'en servir aussi au moins une fois. Mais simplement je trouve qu'on est loin du paradigme objet originel. Et que chaque langage faisant les choses à sa sauce, on a surtout un paradigme de plus en plus flou.

Du coup ce que je fais moi : J'analyse mon problème en essayant de définir les différents types de données qui interagissent entre eux, j'appelle ça des classes et dedans je regroupe les fonctions qui pourraient connaitre la représentation interne du type en FP, ce qui correspond en gros aux fonctions pouvant manipuler $this en PHP. Je mets ces fonctions dans ma classe. On parle ici des fonctions public puisque les autres c'est moi qui choisit ce que j'en fais.

Et au final tout le monde est content. Après avoir bien regardé le code de Laravel je me rends compte que en fait tout le monde fait comme ça (enfin du moins la lecture du code permet de mettre en évidence ce type d'organisation, rien de nouveau au final). Mais je trouve, comme dans l'article d'oxman, qu'on ferait mieux de s'en tenir aux types de données et à leurs interfaces, au coeur du problème, au lieu de multiplier les classes. Est-ce que chaque classe doit vraiment implémenter des putters en plus de getters maintenant ?

Petite propagande perso : les seuls moments ou j'ai l'impression de faire de l'objet de façon naturelles (i.e. sans me demander toutes les trois secondes si je donne telle responsabilité à la bonne classe) c'est avec Erlang, où je bénéficie de l'envoie de message pour les appels de méthodes et pour les return et de l'isolation totale (dans les limites de la machine) de mes objets. (Bon et du polymorphisme mais on l'a aussi de façon très satisfaisante en PHP via l'héritage et les iterfaces).


RE: Compass : East Oriented - niahoo - 10-08-2014

Pour les implémentations du style Machin.putTruc(System.out) je suggère de regarder dans code des appli symfony/laravel, tout le code concernant l'I/O sur le namespace Symfony\Component\Console. C'est très instructif.


RE: Compass : East Oriented - Sephi-Chan - 10-08-2014

C'est un peu ce que j'avais compris du message que je t'ai demandé de clarifier.

Après avoir fait un peu d'Erlang — où l'envoi de message est très concret avec les acteurs — j'ai réalisé que je brisais le principe d'envoi de message (pourtant cher au modèle objet) à chaque fois que j'utilisais la valeur de retour d'une méthode publique.


RE: Compass : East Oriented - srm - 10-08-2014

Je comprends pas très bien ce que tu expliques niahoo.
C'est pas parce que tu peux coder ton objet sale que tu dois le faire, c'est un peu comme la programmation fonctionnelle, tu peux l'utiliser n'importe comment, c'est pas pour ça que la programmation fontionnelle est nulle.

Et l'article East pousse justement le concept "tell don't ask" et donc "t'interdit" de travailler avec des méthodes privées de l'objet, donc c'est cool.

Je vois pas en quoi ton exemple est faux ou alors on ne doit pas faire ça.
Il est juste en tout point, si par exemple tu avais un système d'encapsulation d'objet (par exemple tag et tag parent) ça peut être du code cohérent et en plus qui marche comme prévu.

Et vu que justement on dit tous dans ce topic (si j'ai bien suivis) qu'utiliser les propriétés privés avec des getter c'est mal, pourquoi alors vous pensez (si j'ai bien suivis) que la méthode East c'est trop overkill ?


RE: Compass : East Oriented - niahoo - 11-08-2014

(10-08-2014, 06:05 PM)srm a écrit : Je comprends pas très bien ce que tu expliques niahoo.
C'est pas parce que tu peux coder ton objet sale que tu dois le faire, c'est un peu comme la programmation fonctionnelle, tu peux l'utiliser n'importe comment, c'est pas pour ça que la programmation fontionnelle est nulle.

Ce que je dis c'est que les langages fonctionnels comme Haskell ou Erlang ont généralement tendance à pousser le développeur à faire de la programmation fonctionnelle. Alors que les langages comme PHP te fournissent tout un tas de bordel et tu as cinquante devs différents qui te proposent de structurer tes classes plutôt comme ceci ou comme cela. En FP bien sûr tu as plusieurs façons de faire mais comme le paradigme est simple on en revient toujours à Type-de-données-en-entrée/Type-de-données-en-sortie pour les fonctions, qui auront toujours une valeur de retour (à l'exception des fonctions qui ne retournent jamais); tandis que les envois de messages n'auront jamais de valeur de retour (en fait si, le message lui-même, vu que c'est une fonction qui envoie, mais ceci est un détail d'implémentation). Du coup quand tu implémentes un objet avec un getter tu envoies clairement un message question puis un message réponse. Je trouve donc que dans les langages FP que j'utilises les choses sont plus claires. En PHP on peut faire de l'objet, ou pas, du simili objet, mais en aucun cas l'implémentation ne t'incite à faire quelque chose de propre, vu qu'elle est juste pompée sur Java/C++ qui faisait la même chose des années auparavant.

Ici il ne faut pas te tromper, je parlais de PHP en tant qu'implémentation d'un langage OO. Je ne parle pas en soi des paradigmes OO et FP qui valent ce qu'ils valent et qui sont parfois complémentaires comme en Erlang.

(10-08-2014, 06:05 PM)srm a écrit : Et l'article East pousse justement le concept "tell don't ask" et donc "t'interdit" de travailler avec des méthodes privées de l'objet, donc c'est cool.

Qu'est-ce qu'une méthode privée ? Est-ce un objet qui s'envoie un message à lui même et qui le traite de suite ? Non, c'est une bête fonction qui agît (ou pas) sur le state de l'objet (une « méthode » donc) ou une fonction utilitaire qui n'intéresse que l'objet (une fonction tout court).

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.

Donc voilà c'est pour ça que pour mon code, j'assume faire plutot du procédural organisé en classes, et je crée mes classes par rapport aux données que j'utilise. Donc en gros des model, des collections, des vues, des controlleurs si c'est du web, et des « applications » ou managers qui ont en gros la responsabilité de ce qui doit être fait i.e. le code métier, en s'appuyant sur tout le reste.

Moi j'appelle ça de l'objet parce que c'est plus simple, mais ce sont des objets au sens PHP du terme, des instances de classes, on n'est pas dans le « vrai » (pour ce que ça veut dire) paradigme objet. Généralement ça convient à mes collègues.

(10-08-2014, 06:05 PM)srm a écrit : Je vois pas en quoi ton exemple est faux ou alors on ne doit pas faire ça.
Il est juste en tout point, si par exemple tu avais un système d'encapsulation d'objet (par exemple tag et tag parent) ça peut être du code cohérent et en plus qui marche comme prévu.

Ce qui me gène dans mon exemple, c'est que $a1 peut accéder au membre privé v de l'objet $a2 dans la méthode foo sous prétexte qu'il est de la même classe. Si j'implémente un système d'humain, est-ce que niahoo peut accéder au cerveau d'oxman et savoir pourquoi il a changé de pseudo sans le lui demander via une méthode publique ? Non. Du coup, ma compréhension du paradigme objet conçoit bien l'isolation entre objets de type Humain alors que PHP lui propose au développeur d'outrepasser cette isolation. Est-ce juste ou faux ? je ne sais pas, mais ça ne me semble pas très malin en tout cas. Parce que le développeur qui voudra faire de l'objet mais qui n'est pas sur de faire du « bon » objet aura cette possibilité alors que je crois perso qu'il ne devrait pas. ça renifle le futur bug bien pérave à plein nez. Du moins à mon humble avis, je ne suis ni un expert ni un fan de l'OO donc je peux tutafé me tromper.

De la même manière, $b accède à $a2->v alors qu'il est private et non protected. Bon, ici ça ferait planter $b->foo donc c'est plus simple comme ça. Est-ce un choix judicieux ou bien faudrait-il être plus strict ? Moi ça me convient comme ça. Mais du coup on en revient au problème de mon paragraphe précédent qui, là, ne me convient pas du tout. Et pourtant je me rappelle plusieurs fois avoir implémenté des méthodes statiques qui utilisaient les privates des objets de la classe. C'etait beaucoup plus simple donc je l'ai fait, mais j'ai quand même testé avant car cela n'allait pas de soi pou moi que cela fonctionne ; et ensuite j'ai pas mal hésité car ça ne me paraissait pas propre.

(10-08-2014, 06:05 PM)srm a écrit : Et vu que justement on dit tous dans ce topic (si j'ai bien suivis) qu'utiliser les propriétés privés avec des getter c'est mal, pourquoi alors vous pensez (si j'ai bien suivis) que la méthode East c'est trop overkill ?

Et bien, du coup si on considère qu'on envoie un message, utiliser un getter qui ne fait que renvoyer la valeur me semble approprié. En Erlang par exemple tu n'as pas le choix. Mais souvent on trouve des objets (y compris dans le code de Laravel que je prend comme modèle de qualité) qui ne sont là que pour représenter des données, et dans ce cas on mets les propriétés publiques car c'est plus simple. Mais c'est moins solide. Le getter te donne du contrôle parce qu'il permet d'avoir un membre privé mais tout de même lisible, donc je ne dirais pas que c'est mal, par contre à la lecture ça fait quand même un peu boulet si au final on a implémenté le setter et qu'il ne fait rien de spécial non plus.

Pour le côté overkill, je trouve qu'un système de log devrait se baser sur un putter qui reçoit en paramètre un flux, ça me paraît très intelligent, et on peut le voir dans le code de Monolog ou de Symfony sur le composant console (voir posts précédents). Sur un système de gestion de compte bancaire putBalance(Stream s) me paraît pas si utile car ton solde sera toujours affiché avec du formatage. Par exemple sur une page web, je vois mal Symfony commencer à faire un output du HTML, puis appeler putBalance puis finir le HTML. Hmm... à moins de passer une closure mais déjà ça sera relou à faire je crois, et en plus ça peut amener à un style totalement basé sur CPS (Continuation Passing Style) (voir les commentaires de l'article et voir plus loin).

Ensuite, Arnadus l'a bien fait remarquer, pour les autres exemples de l'article on multiplie les classes inutilement, ce qui donne un code virtuellement magnifique au niveau de l'abstraction mais chiant à lire et long. Plus de lignes, plus de bugs. Je ne fais que paraphraser ce qu'on a déjà dit donc je ne m'étends pas sur ce point.

On dirait des fois que les mecs qui sont à fond dans l'OO "y croivent" que l'abstraction se fait uniquement en objet. L'abstraction c'est comme une drogue. C'est très sympa et très fun mais l'overdose arrive vite et ton code, comme après avoir fumé un très gros joint, ne fait plus grand chose. Mis à part peut-être décorer les colonnes d'un blog de développeur. Et j'ai l'impression que les plus gros drogués à cette came sont les fans d'OO. Pour moi l'abstraction réside plutot dans les types de données réelles, qu'il faut bien délimiter, sur lesquels on va créér nos types en FP ou nos classes en OO. Elle ne réside pas dans le fait d'ajouter plus de classes. Bon là c'est un avis/goût plus perso peut-être.

Mon post est un peu long, je rentre de ouikande j'ai pas grand chose à glander, j'espère que vous aussi. Sinon désolé.

Ah, et j'ai failli oublier, il faut que j'en rajoute une louche. Le CPS. Le CPS c'est parfois très utile voir indispensable, par exemple pour implémenter les monades en Haskell ou Erlang. On met quelques lignes de codes, on tell un objet de faire quelque chose et on lui passe aussi une callback. Donc voilà, c'est pratique, mais ça reste relativement peut utile. Sauf ... sauf en Javascript, ou les mecs qui ont défini ce langage n'étaient pas assez éveillés pour implémenter sleep ; ironie du sort. Du coup en Javascript et notament sur Node on a du CPS partout partout, parfois masqué comme sont masqué les envois de messages sur Erlang/OTP. Mais là en matière d'OO c'est bizzare. J'envoie à un objet un message, sans retour, mais du coup j'implémente le reste de ma méthode dans une callback que cet objet va à son tour appeler. Sauf que dans la callback c'est mon propre état (à moi l'appelant), potentiellement private, qui sera généralement décrit. Et ça je trouve ça moyen voire crados. Mais c'est parfois indispensable et tout à fait correct du point de vue du langage.

Donc pour conclure : L'objet, très bien, East, super ! mais il faut aussi savoir rester simple, aller droit au but et passer à autre chose, et je trouve que l'auteur ne montre pas ça. Oui tout ça pour ça, mon post n'est pas l'exact exemple de ce que je raconte Smile

Et puis surtout, au lieu de faire de l'abstraction dans tous les sens, ils pourraient pas faire évoluer leur langage pour éviter ce genre de verbiage :
Code :
return (Movie[]) allMovies.toArray(new Movie[allMovies.size()]);

hein ?

Héhé, pas fini, je trouve aussi sa définition du Nord et du Sud pas très convaicantes en regardant au hasard quelques classes de mon code, pas vous ?


RE: Compass : East Oriented - Xenos - 11-08-2014

Citation : Le getter te donne du contrôle parce qu'il permet d'avoir un membre privé mais tout de même lisible
Perso, je n'aime pas cette façon de voir (c'est peut-être qu'une question de formulation). Pour moi, le getter en lui-même ne fait pas sens s'il laisse transparaitre le fonctionnement interne de la classe (impossible de supprimer l'attribut privé sans modifier le sens, dans la documentation, du getter).
Je sais que "modifier c'est mal", mais modifier le fonctionnement interne (attributs privés par exemple) d'une classe n'est pas censé avoir d'impact sur les codes extérieurs ni sur la documentation publique (celle à destination de ceux qui utilisent la classe et non de ceux qui la maintienne).
Ok pour dire "$humain->getBrain() renvoie le cerveau de l'humain", mais ce n'est pas forcément un attribut de la classe Humain.

Getter/Setter sans autre utilité que définir/renvoyer la variable peuvent faire sens en PHP grâce au type hinting: le setter n'acceptera que des objets d'une interface donnée, alors qu'une propriété publique accepte tout.

L'hyper-abstraction, on appelait cela "l'effet chercheur" à l'ECN ^^ Un code théoriquement parfait mais ingérable humainement (surtout en petit groupe voire seul)... Probablement gérable si on utilise un outil spécial "gestion de projet abstrait à millions de classes".


Après, je pense que l'approche la plus adaptée dans le cas de l'objet, c'est vraiment la vue subjective: essayer d'avoir une vue d'ensemble d'un projet orienté objet me semble insensé.
Cela devrait vraiment ressembler à sac de noeuds vu de l'extérieur, avec des éléments sans "flot principal", qui laisse vraiment émerger de nouvelles possibilités (sinon, c'est du procédural déguisé).
J'aime bien voir l'OO comme le Web: une toile, avec des noeuds (les sites = les classes), que l'on peut modifier/ajouter/enlever indépendamment, sans demander à un contrôleur "maître", les interconnecter et oublier toute notion de "flot principal" pour ne plus voir que qu'un objet à la fois avec son environnement extérieur (les autres classes) et sa composition interne.
Mais bon, c'est dur d'avoir une approche type "je fais un projet sans le maîtriser entièrement"...



Question bonus:
Je préfère ceci:
Code :
size = allMovies.size()
myMovie = new Movie[size]
allMoviesArray = allMovies.toArray(myMovie)
return (Movie[]) allMoviesArray;

à cela:
Code :
return (Movie[]) allMovies.toArray(new Movie[allMovies.size()]);

car chaque ligne est alors élémentaire (une classe ne gère qu'un truc, une méthode ne fait qu'une chose, une ligne n'exécute qu'une seule action), d'autant plus qu'en cas de changement de source (exemple: size vient maintenant de la méthode .length() ou même d'un paramètre), la modification de code est simplifiée (une ligne à changer au lieu de fouiller le contenu d'une ligne).
Et vous, que préférez-vous?


RE: Compass : East Oriented - srm - 11-08-2014

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

(11-08-2014, 05:34 PM)niahoo a écrit : 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 Wink

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é Confusediffle:


RE: Compass : East Oriented - niahoo - 11-08-2014

@Xenos : pas compris. Puisque tu as un getter, tu peux très bien enlever la variable private, la renommer ou autre. Justement le getter te permet de faire ce que tu veux avec. Il ne faut pas considérer que ça laisse transparaitre le fonctionnement de ta classe. Après tout, le code extérieur n'est censé connaître que l'API de ta classe.

Concernant l'exemple de code, je suppose que c'est une matière de goût. j'aime plus la seconde car même pour changer le nom de "size" en "length" ça reste facile. Bien sûr je tens à découper aussi si çà deviens trop bordélique. ça dépend on dira Smile.

Je m'inquiétais plus de la nécessité de devoir caster en Movie[] une variable créée à partir d'un Movie[] vide. C'est con non ? J'aurais cru que le Movie[] vide passé en paramètre permettait justement de définir le type de tableau. Pourquoi ce cast !

Bon je connais pas le langage.

@oxman : je soulève plusieurs points auxquels tu ne réponds pas. c'est à ça que servent les messages longs. Mais puisque tu sembles t'intéresser uniquement à quelques uns de ces points, je vais essayer de faire court.

Je veux bien des exemples de langages fonctionnels qui t'incitent à coder en pas fonctionnel. Je crois volontiers qu'il y en a mais je pense que c'est beaucoup moins important que les langages OO. Tu n'as pas le droit d'utiliser OCaml sinon c'est trop facile.

Pour $a1 etc ce n'est pas une mauvaise implémentation. Si tu parles de celle de PHP c'est un choix débattu, si tu parles de mon code, tu peux le tester et il fonctionne. Comme je le disais on s'en sert dans les static.

Citation :Ceci dit ton exemple ne peut pas se produite si on programme en East, car on demandera jamais à un objet sa variable
Oui sauf que tu peux le faire, que PHP t'invite gentiment à faire de la merde et que si tu n'as pas lu l'article sur le East tu vas produire un code de merde. Donc merci PHP. C'est pour ça que le dev fait de la merde (le point que tu demandais à expliciter dans mon post). Pas parce qu'il en a envie.

CSV est un .... (roulement de tambour) ... format ! Merci pour cette barre de rire. Et donc pour lister les comptes d'une centaine de client chaque accompte du client va recevoir l'output et y poser son petit chiffre. Moui c'est intéressant, pourquoi pas si toute la base de code est en East faut voir ce que ça donne.

ton <p><?php $account->putBalance(new HTML()) ?></p> est bien curieux. je suppose que c'est l'équivalent de <p><?php echo $account->getBalance() ?></p>. C'est naze (<- argumentation plus courte).

Citation :Concernant le fait qu'il y ai plus de classe : assurément, mais est-ce un mal ?
Oui c'est chiant.

Pour ton ORM (bon déjà pourquoi faire un nième ORM) je veux bien voir les codes avant/après je pense que ça peut intéresser pas mal de monde ici.


RE: Compass : East Oriented - srm - 11-08-2014

Enfin j'ai l'impression que la discussion ne va pas dans le bon sens. En soit on s'en moque de ce que permet comme bêtise un langage non ?

Je vais voir pour sortir un extrait de code avant/après.


RE: Compass : East Oriented - niahoo - 11-08-2014

Elle ne va pas dans ton sens non. Fais du East si ça te convient, personne n'a dit que c'était mauvais. C'est toi qui m'a questionné sur ce que je disais. Si East te donne une structure sympa en plus du langage c'est très bien.

Non mais si ton ORM fait que 600 lignes et que tu as pu le transformer entièrement en East (vu que tu donnes le nombre de fichiers/lignes pour comparaison) y a pas vraiment besoin de faire un extrait, balances tout.

edit à moins que ce ne soit privé je comprends.