Compass : East Oriented

[niahoo]

Ben genre un système de cache HTTP pour wordpress par exemple. Perso je travaille très rarement sur des trucs from scratch. ça doit pas être trop méchant puisque de toute façon tu peux pousser la réponse "vers l'Est".

[srm]

Pour information j'ai commencé quelque chose.
Mais après divers échanges sur mon routeur il faut que je réanalyse plusieurs choses vis à vis de celui-ci pour l'améliorer et avoir un code plus clean et souple.

[Xenos]

En fait, si je comprends bien, cela revient un peu à coder sans utiliser le mot clef "return"? (je crois que cela a déjà été dit >.<)

Je m'y étais essayé, dans un simulacre de réseau neuronal: c'est assez sympa à réaliser, et cela ouvre de sacrées possibilités niveau extension; mais cela laisse aussi la part belle à l'émergence, en bien (façon feature inattendue et bonne surprise) comme en mal (façon Mandelbug ou Bohr bug). Si vous le voulez, j'essaie de voir si je peux le diffuser en GPL.

[niahoo]

T'embête pas oxman, je sais bien que tu peux y arriver.

[srm]

J'ai grandement amélioré (enfin selon moi) mon Router en east : https://github.com/oxman/router

[srm]

zéro réponse pas mal

[Xenos]

Une question: comment se construirait un Astar ou tout autre algorithme de groupe en East, sans parallélisme ?

[srm]

Une question: comment se construirait un Astar ou tout autre algorithme de groupe en East, sans parallélisme ?

Je sais pas, je suis nul en algo et j'aime pas ça, donc je ne vais pas m'y essayer

[Xenos]

    

    public function destinationFor(Origin $currentOrigin)

    {

        foreach ($this->routes as $route) {

            $route->match($currentOrigin, $this);



            if ($this->signalStop === true) {

                break;

            }

        }



        return $this;

    }

Pour moi, c'est un peu de la contorsion qui ne fait que cacher la conception, plutôt qu'un changement de conception. Je le lis comme une implémentation un peu tordue de

        

        foreach ($this->routes as $route)

            if ($route->match($currentOrigin, $this))

                break;

Car la respo du Router est de passer le Origin aux éléments, dans l'ordre, et de s'arrêter au premier qui lui renvoie un stop (rien n'oblige le return de match() à valoir true si le match a lieu et false sinon: le return de match peut valoir false ou true, peut importe la raison).

    

    public function newRoute(Route $route)

    {

        $router = clone $this;

        $router->routes[] = $route;



        return $router;

    }

De même, je ne comprends pas les clone $this. Le contenu de la méthode est une mécanique interne de l'objet, alors pourquoi cloner (même si, justement, on en a le droit puisque c'est interne)? Les "setter" (peut importe le nom qu'on leur donne) ne me semblent pas casser l'OO "originel" (si on considère qu'ils ne font qu'envoyer un message à l'objet, et non casser l'encapsulation en settant une de ses propriétés); ni même les getter d'ailleurs (si là aussi, on considère qu'on ne get pas une propriété de l'objet, mais une information que l'objet sait nous donner/créer/récupérer).

Dire juste "setter / getter ne servent pas à définir des propriétés de l'objet" (mieux vaut passer la propriété publique du coup, façon Bean) me semble plus pertinent finalement.

'fin bref, finalement, j'adhère pas trop; peut-être parce que PHP n'est pas du tout adapté à l'OO au fond, car l'OO me semble être obligatoirement exécutée sur une architecture parallèle où les thread/entités s'envoient des messages, plutôt qu'une archi série (et PHP ne fait pas de parallélisme entre ses objets).

[srm]

Concernant le signalStop on pourrait faire comme tu dis oui. Sauf que le contrat de ma route (via l'interface) ne permet pas de forcer un type de retour. Ça veut dire que je pourrais changer le type de retour de match sans que mon Router en ai conscience et du coup casser une partie du programme sans forcément le savoir immédiatement. Avec le signalStop je n'ai ainsi plus ce soucis.