Citation :$a1.foo($a2) { $a2->v } me semble aussi sale, de même que le "private sur le scope que tu veux": un élément privé partagé par différentes classes... Ca sent le gaz et l'usine qui va avec :/[quote]
Ah non mail il y a un malentendu. Cette syntaxe est bien sur encore pire qu'un getter. Si tu relis mon code je disais juste que PHP permet ce genre de choses alors que ça va à mon sens à l'encontre de l'OO. Comme le disait oxman si on fait avec East alors on ne touche pas aux variables. D'où la nécessité des getters dans tous les cas.
[quote]Oui @niahoo, le code du getter en lui-même ok, ce qui me gène, c'est la formulation qu'on trouverait alors dans la doc, type "getMachinChose(): getter de l'attribut machinChose", qui est la formulation sous-entendue par ton "Le getter te donne du contrôle parce qu'il permet d'avoir un membre privé mais tout de même lisible" (enfin, c'est ce que j'en ai compris). Bref, okay pour le getter en lui-même pas de soucis, mais pas okay pour dire, dans la doc "cette méthode renvoie la valeur de $this.chose", ou "Human::getBrain(): renvoie l'attribut Brain du Human".
Ok ! Effectivement je me plaçais dans une logique ou on avait à la base un attribut public, et on se dit « hola, pas touche » et *paf* getter. La refactorisation nécessaire après ça est simple donc ça se fait. Mais ensuite oui pour de la doc, la doc doit simplement dire que le getter renvoie telle info, sans dire comment elle est stockée. Note que le code appelant peut savoir que la donnée est tout de même stockée en base de données ; pas forcément.
Ce qui est chiant c'est d'avoir plus de classes que nécessaire. Dans l'article on voit clairement que pour avoir les films par auteur ça prend trois fonctions mais le mec t'envoie une tartine de classes. Alors OK, éventuellement peut-être un jour si dieu le veut et si les planètes sont bien alignées on voudra que l'appli renvoie aussi les films classées par ordre alphabétique inverse du dernier acteur blond de plus de 24 ans et demi à apparaître dans le générique. Mais sinon le finder ça va quoi. Soit ton ORM l'a soit tu t'en passes.
Fes fichiers font la taille qu'ils doivent. Mais j'ai eu par exemple des albums de musique en un seul mp3 avec le fichier d'index qui va avec.
Bon en fait je viens de lire tes exemples de code et quand je vois le code d'oxman et ce qu'il est censé faire (et j'ai pas compris en quoi le 2eme code était plus East), je pense qu'on ne se comprendra pas car tu te shootes beaucoup plus que moi à l'abstraction.
Par contre tu as fait une erreur. Tu as oublié d'implémenter une CommandFactoryFactory qui définit une CommandFactory en fonction du type d'objets sur lesquels la commande va agir. Mais au lieu de t'emmerder à le faire, tu peux simplement utiliser une CommandFactoryFactoryFactory, c'est le plus simple.
(je blague, ça va c'est lisible pour moi).
Et sinon petite digression : un ORM en 600 lignes de PHP ça me ferait rêver. Vous allez casser tous mes rêves avec vos factories. Bon, ma question : Oxman, pourquoi est-ce que tu fais un ORM (question sérieuse, c'est pas du troll). Est-ce ta boite qui veut absolument du code maison, est-ce toi qui les a poussés à choisir une solution maison parce qu'en implémenter un t'intéresse, ou bien ...