Compass : East Oriented

[Xenos]

Le value object TemperatureValue, comment tu le construis? En lui passant une data? Elle ne sera donc pas typée, et le VO devra la checker.

[srm]

Ça tombe bien c'est son rôle de faire ça :-) 

[srm]

La conférence https://www.youtube.com/watch?v=W7KMyzexK-M

[Sephi-Chan]

Sa description de toi est excellente. :p

[srm]

En effet

[Xenos]

J'en reviens quand même aux objections précédentes:

• Si on veut faire de la bio, on la fait jusqu'au bout, et on lance la bouteille à la mer et non à un objet; d'ailleurs, c'est First Come First Served (la première cellule captant la molécule du message détruit cette molécule).

• Les cellules sont des organismes travaillant en parallèle, et non en série: on ne peut pas faire de l'OO pur sur un seul thread

• Que les langages OO actuels comme Java ne soient pas de purs OO, oui, c'est vrai. Mais on se plie au langage qu'on choisit: s'il existe un langage OO pur, sans return, pourquoi pas, cela se tente, mais forcer les langages OO "classiques" à se plier à ce pour quoi ils ne sont pas conçus, c'est inefficace. Surtout quand l'explication est "return me force à retourner un typage donné", alors qu'en PHP ce n'est pas vrai: l'appelé est totalement libre de faire ce qu'il veut.

---

Ce que j'arrive pas à assimiler, c'est surtout la notion que Client::getAgeAskedByBarman serait réutilisable, puisque c'est hyper-spécifique au couple Barman-Client. C'est objecté en fin de conférence: le foisonnement de méthodes devient énorme (et verbeux): statistiquement, il y a plus de risques d'avoir des foirages avec plus de code.


Heu, la partie du Barman qui s'instancie, je trouve que c'est un mélange avec le StateLess model.


J'ai un doute sur les tests: si la classe testée est totalement libre, alors comment on teste $tv->userWantsToWatchTv? En fait, la notion même de test n'a pas lieu d'être si chaque agent est libre de tout (cool, c'est cela de moins à faire, mais comme en stage, on débouche sur des codes qui font n'importe quoi :\).


Dans l'exemple du Barman qui veut connaitre la religion du Client, en East, il faut ajouter 2 méthodes (Client::religionAskedByBarman et Barman::religionToldByClient) et éditer la méthode Barman::giveAlcool; en classique, il faut ajouter 1 méthode (s'il n'existe pas ou s'il est spécifique au Barman) Client::getReligion/Client::getReligionByBarman. C'est pas plus Opened/Closed que East?


Après, que l'orateur se rassure: tout code West peut être Easté (c'est facilement démontrable). Est-ce que cela en vaut le coup, franchement, au vu des résultats de mon dernier réseau de neurones, j'en doute.

Bonne conférence quand même (quoique le "si on avait l'héritage multiple on s'emmerderait pas", je suis pas d'accord, puisque extends/implements n'ont pas le même but)
J'irai faire un tour sur le channel (ou on fixe rendez-vous histoire d'y être ensemble?)
J'vais aussi publier le code du stage, cela pourrait être un exemple intéressant à reprendre

[niahoo]

… s'il existe un langage OO pur …

Erlang Programming Language

Note que les fonctions retournent forcément quelque chose au sein d'un même processus. Mais l'envoi de messages entre les objets (processus) se fait sans garantie de réception. Ces messages ne sont pas des appels de méthodes mais bien une fonctionnalité spécifique. L'envoi de messages est toutefois encapsulé dans une méthode généralement.

D'ailleurs, dans cette même méthode on attend généralement un message retour avant que la méthode retourne. Et à quoi cela sert-il ? À implémenter des getters … Note que l'on dispose d'un typage fort, ce qui change pas mal la donne.

[Xenos]

Alors, dans ce cas, oui, East est parfaitement adapté à du Erlang et devrait y faire des merveilles (puisque c'est le principe du langage en fait).

De toute façon, dans le design, East ou West nécessiteront une attente quand ils émuleront un getter/retour (l'avantage de West sur ce plan étant que le getter est explicite, alors qu'il est dissimulé en East).

En West, l'appel à un getter attend explicitement son retour (est-ce qu'il y a des langages où un return void ne bloque pas l'exécution?). En East, on se retrouve avec des codes où l'attente est totalement masquée (puisque tout retourne this/void). Je retrouve plus l'exemple où j'avais vu cela (ce devais être ici ou sur un des blogs), je rechercherai ce soir.

[niahoo]

"East" n'a pas de sens en erlang, il n'y a pas d'autre façon de faire. Il n'y a pas moyen de créer un getter entre deux objets (processus), tu es obligé de passer un message.

L'attente du retour est implémentée dans la réception de message elle-même:

getSomeInfos(MyObjectPid) -> %% correspond à MyObject.getSomeInfos()

    Token = make_ref(),

    MyObjectPid ! {getInfos,{Token,self()}},

    receive 

        {Token,Infos} -> Infos

    end.

Ici on envoie un message à l'objet (représenté par sa référence de processus MyObjectPid). Le message comporte un token et self() qui correspond à la référence de processus du code en cours d'exécution (l'appelant dans notre cas), permettant à l'autre objet de nous envoyer un message de retour.


Quand on reçoit un message portant le même token, alors on sait que l'on a reçu dans le tuple les infos que l'on souhaitait. Et on renvoie ça.

[Xenos]

Oui, c'est justement ce que je veux dire: "East n'a pas de sens" car c'est le langage lui-même qui est East, et c'est cette approche que je trouve valable et totalement légitime.

Pour moi, East n'est pas une façon d'utiliser un langage, mais une façon de faire un langage. Du coup, appliquer du East sur un langage qui n'est pas du East (= qui n'y est pas adapté, comme PHP), c'est contre-productif, et ce serait aussi mal venu de faire du East dans un langage inadapté comme PHP que de faire du West dans un langage inadapté comme Erlang.

La croisade du East n'est pas faite pour changer les mentalités des codeurs PHP/Java/C etc, mais pour mettre en avant les spécificités des autres langages comme Erlang.

Le meilleur exemple que je pourrai avancer, ce sont les sites web et l'architecture client-serveur: c'est du pure East (et c'est designé ainsi): le serveur génère une page HTML, l'émet à destination du client, et le client en fait ce qu'il veut. C'est intrinsèquement, dans le fonctionnement du "langage" web, du pure-East. D'où mes remarques quand certains mettent du javascript ou des notions de navigation dans le message HTML: ce n'est pas de cette façon que fonctionne le web, il faut s'y plier, et faire du East. De même, PHP/Java ou d'autres n'ont pas une façon de fonctionner "East-oriented", et il faut faire avec, et s'y plier (bien qu'on puisse lire get/set/return d'une façon qui permet de faire du East quand même).