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 - Max72 - 31-08-2015

Plop !
Débat très intéressant et instructif, merci aux intervenants.

J'ai tout lu, et au début ça avait l'air très séduisant. Je code avec pas mal d'interfaces, d'abstraction, essaye de séparer les responsabilités, découpler les dépendances, ... donc j'avais l'impression que je m'en rapprochais.
Mais au fur et à mesure de la discussion on sent nettement les limites apparaitre, et je trouve ça bien trop rigide et verbeux pour pas grand chose.

Voilà mes 2 francs !


RE: Compass : East Oriented - niahoo - 31-08-2015

argh!


RE: Compass : East Oriented - Max72 - 31-08-2015

J'ai dit une/des conneries ? ^^

Edit : Par contre je n'ai pas saisi le but de cloner des instances de classe (je ne sais plus quelle page) pour les retourner (au lieu de $this).
Quelqu'un se sent le courage d'expliquer en 2 lignes si possible ?
Merci !


RE: Compass : East Oriented - Xenos - 01-09-2015

Si
Scope 1 {
return $truc;
}
Alors du code externe à Scope1 peut altérer $truc sans que Scope 1 ne le sache.

Si
Scope 1 {
return clone $truc;
}
Alors rien ne peut altérer $truc à part Scope 1.


Effets:
• Limiter les altérations d'un Scope par les autres
• Considère que $truc "appartient" au Scope 1
• $truc n'est pas un objet externe autonome, c'est un objet embarqué dans la boite noire Scope 1
• Performances réduites
• Reproduit pour les objets le comportement de copie (lors d'un return) que subissent les données string/int/float
• Pas d'accès à $truc hors de Scope 1, sauf si $truc vient de l'extérieur (il faudrait cloner $truc quand on le reçoit dans le constructeur pour éviter cela)

Pour ma part, l'effet le moins désirable de cette méthode est que $truc n'est pas accessible de l'extérieur, mais il est pourtant "connu": on sait que Scope 1 a une relation avec un objet du même type que $truc, mais sans pouvoir accéder à cet objet.

[PS] J'ai zappé le coté $this, c'était juste pour le return d'un clone d'un objet quelconque (qui n'est pas forcément une mauvaise chose).

De ce que j'en ai retenu, pour $this, retourner une copie est une émulation d'objets "immutable", pour éviter des soucis en cas de parallélisme (donc, totalement inutile en PHP). Cela permet aussi de considérer que l'objet se "connait" à sa création et ne change plus (donc, ça "émule" le mot clef "final" de Java). Mais je me trompe peut-être (puisque je trouve cela totalement inutile et mal placé à mesure que je l'ai écrit...)


RE: Compass : East Oriented - niahoo - 01-09-2015

Les objets immutables sont très utiles : on peut transformer nos données, et si à un moment on rencontre une erreur, on peut repartir avec notre objet de base et faire autre chose. En FP on fait ça constamment et c'est génial.

Ou bien un autre cas (mais beaucoup plus rare) : si tu utilises une event loop genre React, tu es content d'avoir des objets immutables, pour pouvoir les cloner quand tu sers chaque requête.


RE: Compass : East Oriented - Xenos - 01-09-2015

Citation :On peut transformer nos données, et si à un moment on rencontre une erreur, on peut repartir avec notre objet de base et faire autre chose.

C'est le pattern Memento; à ce compte-là, il me semble plus puissant de faire:

Code PHP :
<?php 
class Chose {
// Members & Methods
}
class
Memento {
private
$savedMemento;

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

/// Returns a copy of the stored object so you can restore its state
public function getCopy() {
return clone
$this->savedMemento;
}
}

Ce qui n'oblige pas à passer par ce pattern: on peut altérer Chose sans être obligé de passer par le memento, et ce comportement de Memento est centralisé dans une classe.

(Pour React, j'la ramène pas: je ne connais pas ☺)


RE: Compass : East Oriented - niahoo - 01-09-2015

Ouais enfin ton pattern c'est un moyen d'arriver à ça. Utiliser des objets immutables ça fait plus de trucs quand même. C'est quasiment un paradigme. Normalement, il ne faudrait pas que les objets implémentent spécifiquement une sérialisation, ce à quoi East échoue tout autant puisqu'il faut cloner explicitement.


RE: Compass : East Oriented - Xenos - 01-09-2015

Ouep, ce serait intéressant que ce soit un élément de langage dédié façon mot-clef "immutable".

Les objets n'implémentent pas forcément de "sérialisation" puisque PHP propose une implé par défaut pour clone (l'objet est cloné en surface). Isoler le clonage dans une classe dédié permettrait d'ailleurs de faire un "MementoDeepCopy" par exemple.

Ca offre quoi de plus, un objet "immutable" face à un "Memento" ou face à un objet sans setter & avec getter renvoyant des clones?


RE: Compass : East Oriented - niahoo - 01-09-2015

Ben déjà ça offre de pas devoir le faire explicitement. Wink Et quasiment tout le paradigme FP repose dessus.

Tiens par exemple, tu veux cloner une collection de modèles, il va te falloir implémenter ton pattern memento récursif. Ensuite j'avoue que en PHP single-thread on ne verra pas vraiment les avantages, vu qu'on recrée le monde à chaque requête.

Edit: bon pas très convaincant je me rends compte. Le pattern memento est quand même sympa. D'ailleurs, il est beaucoup plus facile à implémenter dans un langage dont les données sont immutables ! Mais il faut faire attention, en PHP, quand tu reviens en arrière sur un objet, tous les autres objets auxquels tu avait passé la référence de ta première copie doivent être modifiés pour pointer vers la nouvelle copie. Typiquement une collection et un modèle.


RE: Compass : East Oriented - Max72 - 01-09-2015

Merci pour les explications. Toujours pas convaincu par le 'clone' : Si je veux un clone, j'en fait un.
Si je veux un immutable, j'en fais un, mais pas toutes mes classes (j'imagine pas la RAM que ça doit pomper avec tout ces clones).

Je préfère de loin le memento si j'en ai besoin, mais perso j'ai rarement l'utilité de bosser sur des clones d'instance alors peut-être que mon avis est biaisé :/