Compass : East Oriented

[srm]

En l'occurrence moi je connais déjà bien West (toi aussi) et je connais aussi bien East (pas toi) et tu fais tout pour ne pas comprendre East.
Heureusement je t'ai mis un petit lmgtfy

[srm]

Encore une chose, tu aurais regardé la conf East que j'ai linké tu verrais que celui qui a inventé la POO (East) fait parti d'une équipe de pure génie.
Donc bon...

[Xenos]

Pratique de mélanger dans la même sauce instanceof et East
Et puis oui, c'est tellement mal d'utiliser les opérateurs (instanceof) et les mots clefs de langages (return)... Ajoutes donc "php" à ta requête "instanceof bad practice", juste pour voir.
Je peux te sortir de bien plus grosses brouettes de résultats pour "circular dependency bad practice", puisque c'est ce que tu proposes dans tes ping-pongs entre méthodes.

Faudra que tu me montres comment "on y revient petit à petit" si aucun projet concret ne l'utilise.


T'as fait le tour de beaucoup de sophismes, il manquait l'argument d'autorité Eistein aussi est un génie reconnu, cela ne l'empêche pas de s'être plusieurs fois planté. Tiens, y'en a même un Top 23.


J'ai compris East, c'est "return $this et rien d'autre" (sauf les valueobject, cool les règles changent quand on en a besoin...). Je t'ai juste pointé du doigt des endroits où ça pèche.
En revanche, je suis pas d'accord: pour moi, t'as pas l'air de si bien connaitre West que cela, puisque:
• Non, tu n'es pas obligé en PHP de retourner un truc précis. Et en PHP7, si tu implémente une interface au return typé, c'est que ta classe accepte ce contrat, donc c'est normal de s'y plier
• Tu mélanges la signature de la méthode dans une interface à l'algorithme que la classe en implémente

PS: préfère l'edit aux nouveaux messages, surtout pour un question pour un champion 4 à la suite.

PSS: Ce n'est pas parce que tu as découvert East il y a peu et que tu as plongé dedans que East se répand partout et qu'on y revient. C'est un biais cognitif.

[srm]

Si les utilisateurs de PHP étaient au courant des bonnes pratiques de dev ça se saurait.
Donc ajouter PHP à la requête ça a pas vraiment de sens. Et creuse donc les articles et lit les pour comprendre pourquoi c'est pas bien.

Un petit exemple pour les dépendances circulaires : http://stackoverflow.com/questions/24076...each-other
Si j'en avais dans le code que je ferais, il y aurait forcément un var_dump d'un des objets qui ne marcherait pas.
Pourtant ils marchent tous.
A sait parler à B
B sait parler à A
Mais A n'a pas de référence vers B pendant que ce même B à une référence vers A.

On y revient car la plus part des librairies se professionnalisent, utilise des interfaces un peu partout, à droite et à gauche on commence de plus en plus à utiliser des valuesobjets, des valeurs immutables etc. Alors qu'avant tout ça on s'en foutait.

C'est marrant parce que PERSONNE n'a jamais dit que Alan Kay s'était planté quand il a créé la POO.

East c'est pas juste return this, ça va beaucoup plus loin que ça.
On commence par dire que c'est return this pour bien marquer la séparation avec West.
On n'a à ce jour rajouter AUCUNE exception à East.
A chaque fois que mageekguy a rencontré un soucis il y a trouvé une réponse logique sans exception.
Il faut pas confondre méthode de programmation (East) et ce que permet le langage. Tu dois faire des pirouettes avec le langage par moment. Typiquement le getValue c'est juste parce que l'on ne peut pas avoir d'immutable en PHP.
Et tu es juste en train de dire que l'on fait une exception pour les valueObject, donc qu'en gros on ne devrait pas pouvoir avoir la valeur d'une donnée. Comme si tu avais un Int, mais que tu ne pouvais pas savoir de quel valeur est l'Int.

Pour East on est encore TRES LOIN d'y être proche. Mais la plus part des grosses lib sont codées de façon bien différente de maintenant par rapport à il y a 10 ans. Ou c'était vraiment de la POO ridicule il y a 10, c'est déjà nettement mieux, mais il y a encore beaucoup de chemin.

J'ai jamais dit que tu devais retourner un truc précis ou quoi que ce soit que tu racontes concernant West.
Puisqu'en West tu fais ce que tu veux, tu peux faire tout et n'importe quoi sans logique aucune, puisqu'il n'y aucune règle.

[Xenos]

Tu changes de discours comme de chemise: East c'était censé être bien parce que ça laisse la liberté aux objets de faire d'autres trucs ("je te fais confiance pour") et maintenant, West c'est pourri parce que les objets peuvent faire tout et n'importe quoi comme ils le souhaitent...

Au début tu nous dis "West c'est pourri car je suis obligé de retrourner un truc précis: si je veux retourner des chips au lieu de l'or je peux pas", on te montre que PHP n'ayant pas de retour typé, tu peux retourner ce que tu veux et du coup ça devient "West c'est nul parce que le retour est pas typé donc je peux faire n'importe quoi" et même quand on te souligne que en PHP7, tu pourras facultativement typer tes retours (donc forcer un typage à un endroit parce que tu le veux et ne pas le forcer à un autre), ça te convient encore pas.


T'as une dépendance circulaire, t'as juste (encore une fois) pas envie de l'admettre. PHP étant plus souple à ce niveau que d'autres langages (comme le C++), cela n'entraîne pas de problème majeur, mais (histoire de sortir de la zone de confort ), essaie-toi à faire le même code en C++, et tu verras: tu auras besoin d'une forward declaration. Et je me demande même si l'auto-complétion ne va pas sauter avec cette forward declaration.


Alan n'a pas eu tort au départ puisqu'il voulait copier la biologie. Or, dans la bio, la cellule ne fixe pas le destinataire du message. Dès lors, la notion de return est impossible (le return, c'est un message qui part de l'appelé et va vers l'appelant). C'est pas ce que t'as en PHP puisque tu fixes le destinataire du message. C'est donc au niveau du langage que tu veux changer les choses, pas au niveau du code. D'autant plus si tu parles du fait que East oblige à des pirouettes à cause du langage. C'est donc bien un principe de langage et non de code (l'OO est un langage d'ailleurs, pas une façon de coder).
Et accessoirement, en bio, il y a le même ADN dans toutes les cellules (sauf reproductrices ou mutations aléatoires). D'une part, je me sens pas de coder l'ADN complet (d'autant que j'ai pas forcément besoin de coder l'humanité et le monde du vivant complet si je veux juste simuler un joueur d'échecs: cela s'appelle faire un modèle), et cela implique qu'il n'existe qu'une et une seule classe pour toutes les cellules d'un être humain (voire, pour toute l'humanité ou même tout le vivant si l'ADN est vu comme des données de la cellule). Je comprends mieux pourquoi l'évolution s'étale sur des millions d'anées. Perso, j'aimerai aller un peu plus vite que ça


Si c'est "bien plus que return $this", alors y'a quoi de plus?
Avec tes liens, je suis tombé sur History: Alan POO, dont le passage "I realized that the cell/whole-computer metaphor would get rid of data, and that "<-" would be just another message token (it took me quite a while to think this out because I really thought of all these symbols as names for functions and procedures." retranscrit, si j'ai bien compris, ce qu'Alan voulait dire avec l'OO. Je sais pas de quel langage le "<-" vient (j'ai pas réussi à trouver), mais vu l'allure du symbole, j'ai envie de dire que c'est ou du return, ou du assign, donc, du pur West. Mais bon, là, je peux me planter.


Enfin, si instanceof est pas bien, tu dois être capable de me dire pourquoi en 15 secondes, non?

[srm]

Et dans un langage qui gère correctement les immutables, l'override des opérateurs, les unions de type, ça donne ça :

trait Hero

{

   def askGoldByWomen(women: Women): Hero

   def askGoldByKid(kid: Kid): Hero

   def askGoldByWomenKid(women: Women with Kid): Hero

   def ageIs(age: Age): Hero

}



trait Women

{

   def ageIsAskedByHero(hero: Hero): Women

   def giveGoldByHero(gold: Gold, hero: Hero): Women

}



trait Kid

{

   def ageIsAskedByHero(hero: Hero): Kid

   def giveGoldByHero(gold: Gold, hero: Hero): Kid

}



case class Gold(amount: Int) extends Ordered[Gold]

{

   require(amount >= 0)



   def compare(that: Gold) =  amount - that.amount

   def +(that: Gold): Gold = new Gold(amount + that.amount)

   def -(that: Gold): Gold = new Gold(amount - that.amount)

   def *(that: Gold): Gold = new Gold(amount * that.amount)

}



case class Age(value: Int) extends Ordered[Age]

{

   require(value >= 0)



   def compare(that: Age) =  value - that.value

   def *(that: Age): Age = new Age(value * that.value)

}



class Conan(var gold: Gold) extends Hero

{

   var giveGold: Boolean = false



   def askGoldByWomen(women: Women): Hero = {

       if (gold < Gold(2)) {

           return this

       }



       val hero = new Conan(gold)

       women ageIsAskedByHero hero



       if (hero.giveGold == true) {

           gold -= Gold(2)

           women.giveGoldByHero(Gold(2), hero)

           println(s"[Hero] I still have $gold")

       }



       this

   }



   def askGoldByKid(kid: Kid): Hero = {

       if (gold < Gold(1)) {

           return this

       }



       gold -= Gold(1)

       kid giveGoldByHero(Gold(1), this)

       println(s"[Hero] I still have $gold")



       this

   }



   def askGoldByWomenKid(womenKid: Women with Kid): Hero = {

       if (gold == Gold(0)) {

           return this

       }



       val hero = new Conan(gold)

       womenKid ageIsAskedByHero hero



       if (hero.giveGold == true) {

           womenKid giveGoldByHero(gold, this)

           gold = Gold(0)

           println(s"[Hero] I still have $gold");

       }



       this

   }



   def ageIs(age: Age): Hero = {

       if (age >= Age(18)) {

           giveGold = true

       }

       this

   }

}



class Gamin(age: Age) extends Kid

{

   def ageIsAskedByHero(hero: Hero): Kid = {

       hero ageIs age

       this

   }



   def giveGoldByHero(gold: Gold, hero: Hero): Kid = {

       println(s"Goood i can buy candies for $gold");

       this

   }

}



class BBardot(age: Age) extends Women

{

   def ageIsAskedByHero(hero: Hero): Women = {

       hero ageIs age

       this

   }



   def giveGoldByHero(gold: Gold, hero: Hero): Women = {

       println(s"I can feed pet with food cost $gold");

       this

   }

}





class Gamine(age: Age) extends Women with Kid

{

   def ageIsAskedByHero(hero: Hero): Women with Kid = {

       hero ageIs age*Age(3)

       this

   }



   def giveGoldByHero(gold: Gold, hero: Hero): Women with Kid = {

       println(s"I can trick for $gold");

       this

   }

}



class PetitePeste(age: Age) extends Women

{

  def ageIsAskedByHero(hero: Hero): Women = this



  def giveGoldByHero(gold: Gold, hero: Hero): Women = {

      println(s"Easyyyy boy i get $gold");

      this

  }



  def racketer(hero: Hero) = {

      // Ca pourrait venir d'un autre bout de code:

      // Dans un tel cas, bon courage pour débugger 

      hero ageIs age

      hero askGoldByWomen this

  }

}



val conan = new Conan(Gold(300))



val peste = new PetitePeste(Age(20))

peste racketer conan



val bbardot = new BBardot(Age(80))

val gamin = new Gamin(Age(10))

val gamine = new Gamine(Age(9))



conan askGoldByWomen bbardot

conan askGoldByKid gamin

conan askGoldByWomenKid gamine

[srm]

Tu changes de discours comme de chemise: East c'était censé être bien parce que ça laisse la liberté aux objets de faire d'autres trucs ("je te fais confiance pour") et maintenant, West c'est pourri parce que les objets peuvent faire tout et n'importe quoi comme ils le souhaitent...

Non West c'est pourris car il n'y a aucune règle et bien souvent en West une partie de l'algo de l'objet est en dehors de lui et bien souvent une modification de code interne d'un objet en West doit avoir connaissance du monde qui l'utilise.

Au début tu nous dis "West c'est pourri car je suis obligé de retrourner un truc précis: si je veux retourner des chips au lieu de l'or je peux pas", on te montre que PHP n'ayant pas de retour typé, tu peux retourner ce que tu veux et du coup ça devient "West c'est nul parce que le retour est pas typé donc je peux faire n'importe quoi" et même quand on te souligne que en PHP7, tu pourras facultativement typer tes retours (donc forcer un typage à un endroit parce que tu le veux et ne pas le forcer à un autre), ça te convient encore pas.

Non c'est nul parce que tu es obligé de retourner une valeur alors que par moment tu ne veux pas le faire et faire une action qui n'est pas en rapport direct à ton getter au sens ou le getter est censé donner une donnée. Et si tu types le retour tu ne pourras toujours que retourner des chips, en East même avec le retour typé (qui sera self) tu pourras donner des chips, des patates ou ce que tu veux, et tout sera typé. Puisque tu ne retournes pas une donnée tu envoies un message au format attendu par le récepteur. Donc tout ce que le récepteur accepte tu peux lui envoyer.

T'as une dépendance circulaire, t'as juste (encore une fois) pas envie de l'admettre. PHP étant plus souple à ce niveau que d'autres langages (comme le C++), cela n'entraîne pas de problème majeur, mais (histoire de sortir de la zone de confort ), essaie-toi à faire le même code en C++, et tu verras: tu auras besoin d'une forward declaration. Et je me demande même si l'auto-complétion ne va pas sauter avec cette forward declaration.

Dépendance circulaire peux être, référence circulaire non. En Scala ça pose aucun soucis, donne un bout de code en C++ que je test et on verra.

Alan n'a pas eu tort au départ puisqu'il voulait copier la biologie. Or, dans la bio, la cellule ne fixe pas le destinataire du message. Dès lors, la notion de return est impossible (le return, c'est un message qui part de l'appelé et va vers l'appelant). C'est pas ce que t'as en PHP puisque tu fixes le destinataire du message. C'est donc au niveau du langage que tu veux changer les choses, pas au niveau du code. D'autant plus si tu parles du fait que East oblige à des pirouettes à cause du langage. C'est donc bien un principe de langage et non de code (l'OO est un langage d'ailleurs, pas une façon de coder).

J'appelle ça une pirouette car intellectuellement tu admets pas que je dois faire getter sur un valueObject, ou une interface composé parce que le langage sait pas faire d'union de type. Il a pris comme modèle de départ la biologie, il n'a pas eu pour but de la copier exactement, sinon la POO serait de la programmation en réseau de neurones ce qui n'est pas du tout le cas.

Et accessoirement, en bio, il y a le même ADN dans toutes les cellules (sauf reproductrices ou mutations aléatoires). D'une part, je me sens pas de coder l'ADN complet (d'autant que j'ai pas forcément besoin de coder l'humanité et le monde du vivant complet si je veux juste simuler un joueur d'échecs: cela s'appelle faire un modèle), et cela implique qu'il n'existe qu'une et une seule classe pour toutes les cellules d'un être humain (voire, pour toute l'humanité ou même tout le vivant si l'ADN est vu comme des données de la cellule). Je comprends mieux pourquoi l'évolution s'étale sur des millions d'anées. Perso, j'aimerai aller un peu plus vite que ça

Encore une fois il faut arrêter d'aller si loin. Quand on fait de la programmation on copie le monde qui nous entoure dans une certaine mesure. Quand tu fais un objet Car en West est-ce que tu as une propriété pour la centaine de milliers de caractéristiques/composants d'une voiture ?!

Si c'est "bien plus que return $this", alors y'a quoi de plus?

Tous les contrats doivent être fait via des d'interface, des valueObject, du déclaratif, sans doutes d'autres trucs que j'oublie, j'ai pas tout en tête au moment ou je l'écris. Ca vient quand je code.

Enfin, si instanceof est pas bien, tu dois être capable de me dire pourquoi en 15 secondes, non?

Non parce que je n'ai pas le niveau pour te l'expliquer correctement. Quand je t'explique que du coup si tu fais du instanceof tu ne reposes plus sur un contrat (plus sur interface) car le type que tu sais gérer est à l'intérieur de ta classe et pas dans ton API, tu ne comprends pas. Je ne suis pas capable de te l'expliquer mieux que ça, donc je pense que le plus simple c'est que tu lises des trucs sur Internet à ce sujet.

[Xenos]

[srm]

Bon comme je disais il y a une page, tu fais tout pour ne pas comprendre. Donc je lâche l'affaire. Je vais arrêter de perdre du temps avec quelqu'un qui ne veut pas comprendre.

[niahoo]

c'est pas parce-que quelqu'un n'adhère pas a une idée qu'il ne l'a pas comprise.