Effectivement j'ai fais de la boue hier. Mea Culpa - pourtant je sais qu'il ne faut pas essayer d'écrire du code à une heure du mat quand on est claqué...
Ca m'apprendra.
var myPool {
Il manque le = ? Ou ça aurait dû être une définition de fonction ?
Il manque le =
mySocket.on('RST','DESTROY','CLOSE') {
J'imagine que ça aurait dû être mySocket.on(['RST', 'DESTROY', 'CLOSE'], function() {
Oui tout à fait.
La fonction raiseRetryEvent n'est pas définie ici, mais elle n'aura pas accès à curSocket, ce qui paraît bizarre. J'aurais plutôt attendu curSocket.Clients.map(curSocket.raiseRetryEvent.bind(curSocket)), histoire d'avoir d'utiliser une méthode rattachée à curSocket.
C'est une autre façon de faire - j'aime moins car ca duplique des méthodes dans chaque connexion, pour moi la méthode raiseRetryEvent est une méthode de myPool. Comme on est dans le scope, si la fonction n'a pas été surchargée par mySocket il n'y aura pas de soucis.
if(typeof result === 'function')
Ça peut suffire ici, mais il faut faire attention. Il y a beaucoup de choses qui peuvent passer au travers (les classes ES6 sont vues comme des fonctions IIRC, lodash traite aussi de certains cas particuliers : https://github.com/lodash/lodash/blob/4.6.1/lodash.js#L10020).
Certes si je joue avec des lib extérieures et que j'ai pas lu la doc. Mais là j'ai quand même supposément la maitrise de tout le code. J'ai donc le droit de dire que mes clients renvoie soit un callback, soit autre chose qu'une fonction, soit ne renvoie rien.
result(myPool.allocateConnection);
Sans l'implémentation de myPool.allocateConnection, c'est difficile à dire, mais je pense que ça devrait probablement être result(myPool.allocateConnection.bind(myPool));
Là par contre ce serait bizarre, certes je n'ai pas mis le code, mais on se doute que allocateConnection retourne un objet connexion, ou au moins une promesse de connexion à qui en fait la demande. Si le code est correct, il y a peu de chance qu'une telle fonction ait besoin de se référer explicitement à son scope parent.
Ceci étant j'ai voulu (trop) simplifier le code que j'écris d'habitude sur ce genre de cas. Ça plus la fatigue ça devient forcément brouillon.
C'est vrai que
var myCon = myPool.returnPromiseOfConnection(curSocket.Clients[index]);
result(myCon);
aurait été plus lisible.
L'appel à curSocket.cleanup devrait sûrement être en dehors de la boucle.
Clairement oui.
Bref, c'est un bel exemple que le JavaScript est un langage avec beaucoup de pièges.
Oui enfin le fautes de syntaxe et les oublis de keyword c'est de la fatigue pure. JavaScript n'est pas responsable de mes migraines nocturnes non plus.
Après je n'utilise presque jamais bind() dans mon code. Dans ma logique si il y a une fonction qui doit être appelée dans un scope précis, autant l'invoquer depuis ce scope précis. Les mécanismes d'event permettent souvent de faire ça sans grosses difficultés.
Et je pense que les 5 langages que j'ai cités dans mon journal s'en serait tous tirés bien mieux que ça sur cet exemple.
Si on met de coté le fait que j'ai pas exactement servi ma cause en écrivant du code à 1h00 du mat, j'ai un doute.
Elixir peut probablement écrire un code aussi compact et clair pour un codeur Elixir, parce que je sais que c'est possible en Erlang. Maintenant le jour ou il faut trouver un codeur Elixir (ou Erlang d'ailleurs) pour maintenir le bousin parce que le précédent est parti, ca va piquer.
Elm est pas vraiment fait pour ce genre d’âneries. Mais je serai curieux de voir la tête d'un gestionnaire de pool de websockets en Elm. Je n'arrive juste pas trop à avoir un exemple ou ce serait utile ou fun de le faire.
Crystal, je ne pense pas que le langage puisse créer un code aussi compact et lisible. Toute la partie gestion/transmission d'évènements risque d'être plutôt velue sauf erreur de ma part.
les autres je ne les connais pas du tout (non pas que je connaisse les 3 premiers - j'ai essayé mais j'ai pas insisté)
[^] # Re: Opinion personnelle
Posté par Kaane . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 1.
Effectivement j'ai fais de la boue hier. Mea Culpa - pourtant je sais qu'il ne faut pas essayer d'écrire du code à une heure du mat quand on est claqué...
Ca m'apprendra.
Il manque le =
Oui tout à fait.
C'est une autre façon de faire - j'aime moins car ca duplique des méthodes dans chaque connexion, pour moi la méthode raiseRetryEvent est une méthode de myPool. Comme on est dans le scope, si la fonction n'a pas été surchargée par mySocket il n'y aura pas de soucis.
Certes si je joue avec des lib extérieures et que j'ai pas lu la doc. Mais là j'ai quand même supposément la maitrise de tout le code. J'ai donc le droit de dire que mes clients renvoie soit un callback, soit autre chose qu'une fonction, soit ne renvoie rien.
Là par contre ce serait bizarre, certes je n'ai pas mis le code, mais on se doute que allocateConnection retourne un objet connexion, ou au moins une promesse de connexion à qui en fait la demande. Si le code est correct, il y a peu de chance qu'une telle fonction ait besoin de se référer explicitement à son scope parent.
Ceci étant j'ai voulu (trop) simplifier le code que j'écris d'habitude sur ce genre de cas. Ça plus la fatigue ça devient forcément brouillon.
C'est vrai que
var myCon = myPool.returnPromiseOfConnection(curSocket.Clients[index]);
result(myCon);
aurait été plus lisible.
Clairement oui.
Oui enfin le fautes de syntaxe et les oublis de keyword c'est de la fatigue pure. JavaScript n'est pas responsable de mes migraines nocturnes non plus.
Après je n'utilise presque jamais bind() dans mon code. Dans ma logique si il y a une fonction qui doit être appelée dans un scope précis, autant l'invoquer depuis ce scope précis. Les mécanismes d'event permettent souvent de faire ça sans grosses difficultés.
Si on met de coté le fait que j'ai pas exactement servi ma cause en écrivant du code à 1h00 du mat, j'ai un doute.
Elixir peut probablement écrire un code aussi compact et clair pour un codeur Elixir, parce que je sais que c'est possible en Erlang. Maintenant le jour ou il faut trouver un codeur Elixir (ou Erlang d'ailleurs) pour maintenir le bousin parce que le précédent est parti, ca va piquer.
Elm est pas vraiment fait pour ce genre d’âneries. Mais je serai curieux de voir la tête d'un gestionnaire de pool de websockets en Elm. Je n'arrive juste pas trop à avoir un exemple ou ce serait utile ou fun de le faire.
Crystal, je ne pense pas que le langage puisse créer un code aussi compact et lisible. Toute la partie gestion/transmission d'évènements risque d'être plutôt velue sauf erreur de ma part.
les autres je ne les connais pas du tout (non pas que je connaisse les 3 premiers - j'ai essayé mais j'ai pas insisté)