Journal Plonk

Posté par  .
Étiquettes :
22
25
mai
2016

en rapport avec https://linuxfr.org/suivi/liste-de-plonkage-via-regexp et les récents évènements de notre petit monde, au menu: comptes fermés, et utilisateurs spécifiques à ajouter dans le tableau plonk.

je pose ça là:

// ==UserScript==
// @name        DLFPlonk
// @namespace   DLFPlonk
// @include     https://linuxfr.org/*
// @version     1
// @grant       GM_xmlhttpRequest
// ==/UserScript==

//            DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
//   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
//
//  0. You just DO WHAT THE FUCK YOU WANT TO.
//

(function() {
    var plonk = [];
    var articles = document.getElementsByTagName('article');
    for (var i = 0; i < articles.length; i++) {
      var userLink=articles[i].getElementsByClassName('meta').item(0).getElementsByTagName('a').item(0);
      GM_xmlhttpRequest({
          method: "GET",
          url: userLink.href,
          context: articles[i],
          onload:  function(response) {
            if(response.responseText.match(/Compte fermé/)){
              response.context.style.display="none";
            }
          }
      });
      for(var j = 0; j < plonk.length; j++){
        if (userLink.textContent == plonk[j] || userLink.href == "https://linuxfr.org/users/"+plonk[j]){
          articles[i].style.display="none";
          break;
        }
      }
    }
})();
  • # Fonction

    Posté par  (site web personnel) . Évalué à 5.

    Je suis curieux, quel est l'intérêt de définir ainsi une fonction anonyme, pour l'appeler immédiatement, plutôt que de simplement exécuter directement le code correspondant ?

    En clair, pourquoi faire :

    (function() { du code ; })() ;

    plutôt que simplement :

    du code;
    • [^] # Re: Fonction

      Posté par  . Évalué à 10.

      au choix: isoler le code ou étaler mon incompétence :)

      • [^] # Re: Fonction

        Posté par  . Évalué à 5.

        C'est plutôt une bonne pratique en JS que d'isoler le code et encore plus en userscript.
        Dans ton cas, sans isolation ta variable plonk deviendrait globale.

        • [^] # Re: Fonction

          Posté par  (site web personnel) . Évalué à 8.

          Apparemment ce manque de granularité dans les portées des variables a été réglé par l'introduction de l'instruction let.

          • [^] # Re: Fonction

            Posté par  . Évalué à 5.

            il faut donc cocher les deux propositions !!! \o/ !!!
            D'un autre coté, je n'avais pas dit que le choix se voulait exclusif…

          • [^] # Re: Fonction

            Posté par  (site web personnel) . Évalué à 2.

            Et tout ces gens qui se moquent d'haskell ou autre à cause de la présence du mot-clé let vont pouvoir maintenant aussi se moquer de javascript ;)

    • [^] # Re: Fonction

      Posté par  (site web personnel) . Évalué à 5.

      • [^] # Re: Fonction

        Posté par  (site web personnel) . Évalué à 8.

        C'est affreux, de devoir écrire de telles horreurs pour pallier des défauts du langage.

        • [^] # Re: Fonction

          Posté par  (site web personnel) . Évalué à 6. Dernière modification le 25 mai 2016 à 14:11.

          • Pas sûr que ça soit la faute du langage plutôt que son implémentation dans les navigateurs ou ailleurs qui ne te pousse pas à organiser ton code
          • Quoi qu'il en soit c'est sensiblement la même chose en C si tu déclares une variable en dehors d'une fonction (ou dans un script Lua tiens, qui est pas mal utilisé par des projets en C/C++ pour la partie scripting, comme Javascript a été utilisé pour scripter les pages web ; c'est ptêtre inhérent à la simplicité voulue d'un système de scripting)
          • C'est un raccourci pour ne pas nommer un "module" parce que c'est un module ad hoc utilisé seulement à côté de sa définition ; la version verbeuse qui serait (en restant dans du "vieux" javascript, sans utiliser de "nouveau" concepts justement de type modules) var MonModuleMétier = function(…){…}; MonModuleMétier.init(); serait inutilement lourde.

          Je dirais que tu trouves ça affreux parce que ça ne match pas tes regex de "code dont j'ai l'habitude" et parce que c'est du javascript donc t'es obligé de dire que c'est mal.

          • [^] # Re: Fonction

            Posté par  (site web personnel) . Évalué à 7.

            Je ne sais pas, je n'ai rien contre l'usage de fonctions quand ça sert vraiment à quelque chose, mais pour du pur script linéaire, ça m'a l'air de verbiage inutile, ou qui devrait être inutile en tout cas. Je trouve que des trucs comme (function(window){…})(window) sont plus complexes qu'ils ne devraient l'être, et par là même moins lisibles, en particulier comparé à quelque chose comme { … } qui pourrait faire la même chose.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 4. Dernière modification le 25 mai 2016 à 18:58.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: Fonction

                Posté par  . Évalué à 4.

                Comme mentionné là, cela n'est pas du verbiage inutile. C'est une construction tout à fait classique dans les langages fonctionnels (ou ceux comme javascript qui le sont à moitié). Dans le monde objet, on parlerait de « design pattern » (Je ne cautionne pas du tout ce terme, mais c'est une autre histoire).

                J'abonde : je ne programme pas avec un langage fonctionnel, mais je m'y suis essayé plusieurs fois (et j'ai eu à coder pas mal de LISP il y a longtemps), et ce genre de construction ne me semble pas plus absconse que ce qui doit être fait pour implémenter l'équivalent d'un foncteur ou un fonctoïde en C (à grands coups de pointeurs de fonction1).

                Pire : au moins en Perl, malgré l'existence de my, our, local, etc., on a parfois besoin de recourir à quelque chose d'équivalent. C'est un prix à payer pour la flexibilité du langage. Bref. Je trouve qu'il n'est pas pire d'écrire un truc du genre

                (function(arg1, arg2, arg3) {
                    // code
                })(p1,p2,p3); // pas besoin de nom puisqu'on ne va jamais réellement rappeler ce code plus tard.

                … plutôt que

                var f = function(arg1, arg2, arg3, ...) {
                    // code 
                }
                f(p1,p2,p3); // on appelle la fonction une seule fois ici

                En Java il y a aussi des idiomes similaires, par exemple :

                // Création d'un nouveau thread "anonyme"
                (new Thread( new Runnable() { 
                    // Nouvelles variables ici
                    public void run() {
                        // code
                    )
                }).start();

                Il y a tout un tas de subtilités sur comment/quand tu peux rajouter des variables et quelle syntaxe adopter que je n'ai pas le courage de me remémorer. Maintenant que Java est quand même mieux fichu en termes de syntaxe, etc., ces constructions sont peut-être considérées comme archaïques, mais pendant un bon moment c'était quelque chose qu'on pouvait retrouver couramment dans du code.


                1. Et généralement, on finit par utiliser typedef partout tellement c'est compliqué de correctement écrire ce qu'on veut lorsqu'on commence à avoir des tableaux de pointeurs de fonction ou pire… 

                • [^] # Re: Fonction

                  Posté par  . Évalué à 3.

                  En Java il y a aussi des idiomes similaires, par exemple :

                  // Création d'un nouveau thread "anonyme"
                  (new Thread( new Runnable() { 
                      // Nouvelles variables ici
                      public void run() {
                          // code
                      )
                  }).start();

                  Il y a tout un tas de subtilités sur comment/quand tu peux rajouter des variables et quelle syntaxe adopter que je n'ai pas le courage de me remémorer.

                  Alors c'est un peu différent car tu lance un thread système séparé. Ça me semble logique que ce soit un peu plus sophistiqué.
                  Si tu parle de la création de classe anonyme, oui c'est vraiment moche et les lambdas sont là pour supprimer la plupart des cas où tu avait à en faire.
                  Pour les règles de captures, ça n'est pas très compliqué (à ce que je sache). Tu peut capturer toute variable final (ou effectivement final en java 8). C'est avec les lambdas du C++ que les règles de capture de contexte sont très complexes.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Fonction

                    Posté par  . Évalué à 2.

                    Oui, je pensais aux lambdas qui simplifient pas mal de choses.

                    Ensuite, de mon point de vue de chercheur en parallélisme (« argument » d'autorité, je sais), franchement, créer une fermeture ou un thread dans un langage « fait pour »1, c'est très proche au final. :) Après tout, il faut capturer le contexte, puis appliquer un traitement dessus avec par-dessus le marché des paramètres qui, eux, peuvent varier. Bon ben, la différence entre une fermeture et un thread à ce niveau c'est que le thread peu en plus s'exécuter en parallèle.

                    Et surtout, je trouve que la syntaxe n'est ni plus ni moins compliquée que pour d'autres langages qui chercheraient à faire quelque chose d'équivalent. Par exemple en Perl, pour créer une fermeture on peut écrire ainsi :

                    # Exemple complètement artificiel.
                    my $fixed_arg = shift @ARGV;
                    my $cmp_fixed_arg_with = sub { 
                        my $operand = shift;
                        return $operand <=> $fixed_arg;
                    };
                    say "$fixed_arg " . ($cmp_fixed_arg_with($_) == 0 ? '==' : '=/=') . " $_" for (1 .. 100);

                    On peut trouver ça « naturel » ou « intuitif » ou au contraire « compliqué ». Je pense que c'est principalement un problème d'habitude et d'exposition à des langages divers.


                    1. Pour moi, les règles de portée lexicale en Javascript (ou en Perl, ou en …) sont quand même très bien définies, et la façon de limiter cette portée parfaitement logique quand on considère la syntaxe du langage en lui même. Donc le langage permet de relativement facilement créer ce dont il est question dans ce fil de discussion. 

              • [^] # Re: Fonction

                Posté par  (site web personnel) . Évalué à 1.

                Tous les langages ne possédant pas de constructions pour augmenter la syntaxe sont appelés à devenir des mastodontes horribles difformes tel C++ et ses 5000+ pages de standard, ses tonnes de constructions syntaxiques.

                Je suis d'accord que c'est le cas pour un langage dont la philosophie est de pouvoir accumuler toutes les fonctionnalités et raccourcis qui semblent ou sembleront un jour utiles (je suppose que c'est pour ça que Rust a des macros). Mais des langages avec une philosophie différente (genre go, qui n'a plus de nouvelles fonctionnalités langage depuis un certain temps), s'en sortent avec une petite spécification et pas de macros, et sont pourtant pratiques pour bien des problèmes, et leurs choix niveau langage ont certaines bonnes conséquences ailleurs (simplicité de l'implémentation, donc temps de compilation rapides, par exemple, et simplicité de réaliser de bons plugins pour les éditeurs, etc.).

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 2. Dernière modification le 26 mai 2016 à 20:30.

                  Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Re: Fonction

                    Posté par  (site web personnel) . Évalué à 2.

                    Tu as du loupé le jour où ils ont réinventé les macros.

                    Oui, ils utilisent parfois (pas si souvent) la génération de code, comme une version limitée de macros, de la même façon que des choses comme yacc l'ont fait depuis longtemps pour des cas spécifiques, et sont utilisés aussi de cette même façon externe dans d'autres langages, même parfois s'ils ont des macros. Ceci dit, la méthode de go ne vise même pas à réimplémenter le préprocesseur C, car c'est plus externe : à la fin, les fichiers sont tous des fichiers pur go sans macros, ce qui a l'avantage de ne pas compliquer l'analyse par analyse statique, en particulier utile pour les éditeurs. Ces « macros » ne font pas partie du langage : il se trouve juste que, pour faciliter l'utilisation, des annotations dans les commentaires sont reconnues par des programmes externes (mais ça reste des commentaires, contrairement au C, où le fichier qu'on édite n'est pas en soit une version « finale »). Et je ne dis pas qu'une méthode ou l'autre est meilleure, juste que les propriétés qui en découlent sont différentes.

                    Après, si tu écris un programme où tu sens que tu vas passer ton temps à faire de la génération de code, go n'est évidemment pas le langage à utiliser. Mais avec juste la syntaxe et fonctionnalités de base d'un langage, on peut en général s'en sortir très bien pour les domaine de prédilection du langage. Il faut juste accepter que, parfois, il faut utiliser un autre langage (quand je veux faire un script, je fais du Perl, quand je veux des perfs et typage statique, mais rien de trop compliqué, j'utilise go, quand je veux manipuler un AST, je fais du OCaml, etc.).

                    Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.—Greenspun's tenth rule of programming

                    On peut à notre époque remplacer C et fortran par bien des langages.

                    Je connais la citation, et je suis en partie d'accord avec. Je trouve juste que c'est pas toujours si simple et que plein de critères entrent en compte, et les compilateurs Common Lisp ne sont pas exempts de défauts : par exemple avec sbcl, produire une image exécutable est lent et donne un gros binaire énorme ; du moins quand j'avais essayé, c'est l'impression que j'en avais eu. Analyser statiquement du code Common Lisp semble pas évident non plus. En pratique, la seule façon de démêler des macros est, que je sache, d'utiliser l'interpréteur, ce qui limite la création de programmes qui traitent du code Common Lisp.

              • [^] # Re: Fonction

                Posté par  . Évalué à 3.

                Smalltalk doit te plaire :)

                Je ne suis pas du tout d'accord avec toi par contre. Pour moi créer des syntaxes à tour de bras rend juste la maintenance plus compliquée. Pour moi c'est de l'overengineering ^^ La construction de syntaxes spécifiques, comme les DSL, devrait se limiter aux quelques parties de l'application véritablement métier. Ce sont des parties où tu veux être le plus proche possible de la spécification (que la transcription code/spécification, dans les 2 sens, soit la plus transparente possible). C'est un peu ce dont je parle ici.

                Vouloir faire ça pour d'autres parties de l'application plus technique, rend juste ton code plus compliqué pour rien. À part à le définir dans la bibliothèque standard (mais du coup ce qu'il manque à javascript c'est une structure pour manipuler l'AST et une bibliothèque standard plus complète).

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 2.

                  Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Re: Fonction

                    Posté par  . Évalué à 2.

                    Je n'ai pas dit cela.

                    C'est l'idée que j'ai cru comprendre quand tu (toi "alenvers") dis que les langages doivent avoir des constructions pour manipuler leur AST et qu'il fallait mettre le reste dans une bibliothèque. Bref tout faire par métaprogramation. Je peux me tromper.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Fonction

            Posté par  . Évalué à 2.

            Quoi qu'il en soit c'est sensiblement la même chose en C si tu déclares une variable en dehors d'une fonction

            D'un autre côté, en C (c'est quand même plus utile en C++ avec les objets, mais bon), on peut faire ceci:

            int main()
            {
              {
                int foobar = 42;
                printf( "%d", foobar );
              }
              ++foobar;
            }

            Et ça ne compilera pas parce que foobar n'est pas à portée. Inutile de rajouter tout un patacaisse de contournements.
            Bien entendu, ce n'est pas commun, et je préfère éviter d'y avoir recours, je préfère faire une vraie fonction, mais parfois, j'ai la flemme.

            Je dirais que tu trouves ça affreux parce que ça ne match pas tes regex de "code dont j'ai l'habitude" et parce que c'est du javascript donc t'es obligé de dire que c'est mal.

            Ou parce que d'autres langages plus anciens permettent de faire la même chose, avec moins de magie noire, et que, peut-être, JS aurai pu s'en inspirer.
            Mais il est vrai que j'ai énormément de mal avec la notion de ne pas avoir besoin de définir un point d'entrée pour un programme, pour commencer.
            Le fait de devoir le faire me semble tellement pratique quand je dois creuser dans le code des autres: un p'tit grep "int main(" -r . (par exemple, peu importe le nom de la fonction qui sert de point d'entrée) et je sais ou que ça commence. Contrairement aux langages qui ne forcent pas ce type de définition.

            Oups, on est pas encore dredi.

            • [^] # Re: Fonction

              Posté par  (site web personnel) . Évalué à 2.

              D'un autre côté, en C (c'est quand même plus utile en C++ avec les objets, mais bon), on peut faire ceci:

              Oui, et ? En javascript aussi tu as un système de portée de variables (c'est justement ce que la construction polémique utilise pour pas polluer le scope global…), je vois pas le rapport.

              Là je ne sais pas comment fonctionne l'extension à laquelle se destine le bout de code du journal, mais si elle est minimaliste au sens "quand je tombe sur une URL qui match j'inclus ton script et yolo", sans imposer de structure ou de convention, il faut bien que le code s'exécute tout seul (ton main ne sera exécuté que parce que par convention c'est cette fonction qui est appelée quand on lance le binaire généré, y a rien de magique). Donc soit on prend le scope global pour chez soi et on fait la première proposition de Tanguy, le code à plat, soit on utilise ce type de structure.

              Rajoute une convention "au chargement j'éxécute ta fonction main" et ça sera exactement pareil, je vois vraiment pas le rapport avec la choucroute.

              Ou parce que d'autres langages plus anciens permettent de faire la même chose, avec moins de magie noire, et que, peut-être, JS aurai pu s'en inspirer.

              Y a aucune magie noire, y a uniquement du sucre syntaxique. Si on commence à taxer ce qu'on connait mal de magie noire, pour moi le fait que quand je compile mon programme ça commence par int main et pas par char* tartempion, c'est de la magie noire.

              Mais il est vrai que j'ai énormément de mal avec la notion de ne pas avoir besoin de définir un point d'entrée pour un programme, pour commencer.
              Le fait de devoir le faire me semble tellement pratique quand je dois creuser dans le code des autres

              Et voilà c'est purement de l'habitude. Perso j'ai l'habitude du développement web avec framework IoC, si je veux voir pourquoi tel appel merde je vais direct voir l'action dans le contrôleur concerné, c'est évident.

              • [^] # Re: Fonction

                Posté par  . Évalué à 2.

                Oui, et ? En javascript aussi tu as un système de portée de variables (c'est justement ce que la construction polémique utilise pour pas polluer le scope global…), je vois pas le rapport.

                Ces 2 commentaires:

                Apparemment ce manque de granularité dans les portées des variables a été réglé par l'introduction de l'instruction let.

                il faut donc cocher les deux propositions !!! \o/ !!!
                D'un autre coté, je n'avais pas dit que le choix se voulait exclusif…

                M'ont donné l'impression que la construction en question était là pour limiter la portée des variables, justement?
                Si c'est bien le cas, alors oui, je trouve ça lourd et moche, parce qu'il aurait suffit de créer un bloc dans d'autres langages pour que le problème soit résolu, et non de créer une fonction qui ne sera appelée au moment même de sa création.
                D'ailleurs, est-ce vraiment impossible en JS de faire ça?

                Rajoute une convention "au chargement j'éxécute ta fonction main" et ça sera exactement pareil, je vois vraiment pas le rapport avec la choucroute.

                Je vois. Donc, en fait, le '()' à la fin de la la définition de la fonction, c'est parer au fait que JS n'ait pas de main défini de manière standard?
                Autrement dit, pour contourner une chose qui m'apparaît comme une limite du langage?
                Quant au rapport avec la choucroute, je te dirais ça quand j'aurai fini ma bière :)

                y a uniquement du sucre syntaxique.

                Certes. Le problème, c'est que l'abus de sucre c'est mauvais pour les dents. Personnellement, je trouve par exemple que le C++11 nous fait utiliser trop de sucre syntaxique pour pas mal de trucs liés aux lambdas. Je trouve ces constructions moches.
                Ben la, c'est pareil.
                Quoique, c'est peut-être même pire (en admettant qu'il soit possible de faire pire que la syntaxe C++ qui entoure les lambda… entres autres.), parce que de la manière ou je vois les choses, c'est du sucre qui est utilisé pour contourner une limitation du langage.

                • [^] # Re: Fonction

                  Posté par  . Évalué à -2.

                  Si tant est que cela puisse aider…

                  Je crois qu'il faut rappeler dans quel contexte cette syntaxe à était popularisé.

                  Le problème est le suivant, sur une page web (node est un autre cas), les scripts sont chargés et appliquer au contexte global.

                  <script src='a.js'></script>
                  <script src='b.js'></script> 

                  Ici a et b partage le même contexte, une variable déclarée dans a est accessible dans b, vis-et-versa.

                  Donc au départ cette syntaxe apparait pour éviter les conflits de nommage de variable entre deux scripts de sources distincts (exemple, les scripts d'analytique chargés par dizaine sur certains sites).

                  A l'époque c'était une avancée appréciable, et appréciée.

                  Il faut préciser aussi que cette structure a était utilisée à un moment donné pour des boucles for mal foutu, exemple,

                  for(var i=0;i<5; i++){
                     setTimeout(function (){console.log(i);}, 1); // affiche 5,5,5,5,5 etc
                  }

                  Résolution pourrie,

                  for(var i=0;i<5; i++){
                     (function(i){setTimeout(function (){console.log(i);}, 1);})(i); // affiche 0,1,2,3,4 etc
                  }

                  Résolution correcte,

                  [0,1,2,3,4].forEach(function(i){
                     setTimeout(function (){console.log(i);}, 1); // affiche 0,1,2,3,4
                  });

                  Pour en revenir à IIFE (Immediately Invoked Function Expression) les parenthèses '()' sont là pour appeler l'exécution de la fonction définie.
                  On peut en avoir plusieurs par scripts, donc ce n'est même pas l'équivalent stricte d'un main.
                  Par contre, en pratique, on s'en sert par convention comme un genre de main, en effet.

                  Cette structure (f(){})() semble être l'équivalent des blocs en C comme tu le cites.

                  Pour finir, cette structure tant à être désuète car on utilise de plus en plus des modules de chargement qui encapsule automatiquement le code dans une fonction pour éviter ces effets de bords d'écrasement de variable (cf AMD, require.js etc), et d'autres trucs.
                  Par ailleurs, avec node, c'est automatique, puisque l'utilisation de require fais ce travail.

                  En ce qui me concerne, est ce que c'est beau, est ce que c'est bien : osef.
                  Lorsque j'écris du node, je n'ai jamais besoin de celle ci,
                  Lorsque j'écris du web, j'utilise un système de build, donc je n'en ai pas besoin non plus et le cas de la boucle for sus cité, c'est vraiment de la m**** d'écrire ce code.

                  quand à savoir si un main serait utile à JS, bof, si j’arrive pas à trouver le main d'un script, je préfère faire autre chose que de m'en servir.

                  • [^] # Re: Fonction

                    Posté par  . Évalué à 3.

                    Si tant est que cela puisse aider…

                    Ça m'a pas mal aidé oui, merci.

                    Le problème est le suivant, sur une page web (node est un autre cas), les scripts sont chargés et appliquer au contexte global.

                    Est-ce une spécification de HTML, ou de JS?
                    Si c'est JS qui spécifie cela, alors il ne me semble pas possible d'invoquer "la faute des autres" (je ne dis pas que tu le fais, attention) et la suite logique serait que JS est bancal.

                    Donc au départ cette syntaxe apparait pour éviter les conflits de nommage de variable entre deux scripts de sources distincts

                    De la même façon que les blocs C (ou C++, et même les fichiers bash à bien y réfléchir).

                    quand à savoir si un main serait utile à JS, bof, si j’arrive pas à trouver le main d'un script, je préfère faire autre chose que de m'en servir.

                    J'ai le même type de raisonnement, c'est pour ça que j'ai du mal avec le bash.
                    D'ailleurs, en pratique, je ne suis même pas sûr que le fameux int main( int argc, char** argv ) soit autre chose qu'une convention.
                    Après tout, les OS reconnaissent aussi int main( void ) comme point d'entrée. Pour moi, c'est juste une convention née d'UNIX (pour lequel le C à été inventé si je ne me trompe), les OS cherchant à exécuter un symbole particulier et il se trouve que celui-ci est main (le C n'inclue pas les paramètres dans la signature) dans le cas de windows, linux, *bsd… D'ailleurs, c'est faux: windows exécute le symbole winmain, pas main (enfin, main aussi).

                    Il n'empêche que c'est une convention pratique et utile. Il m'est arrivé de manipuler du code PHP dans lequel je m'y retrouvais sans trop de problème. Mais quand je me mets en tête de contribuer à un projet avec plusieurs centaines de fichiers source, c'est quand même sympa de pouvoir faire un grep "int main" pour savoir ou commencer.

                    Pour finir, cette structure tant à être désuète car on utilise de plus en plus des modules de chargement qui encapsule automatiquement le code dans une fonction pour éviter ces effets de bords d'écrasement de variable (cf AMD, require.js etc), et d'autres trucs.

                    En ce qui me concerne, est ce que c'est beau, est ce que c'est bien : osef.

                    Personnellement, je considère que ce qui est maintenable est beau, que ce qui est beau est simple, et que ce qui est simple est concis (et bien dans cet ordre). Hors, (f(){})() n'est pas concis, donc pas simple, donc pas beau, et donc difficile à maintenir.
                    Opinion personnelle.

        • [^] # Re: Fonction

          Posté par  . Évalué à 2. Dernière modification le 25 mai 2016 à 16:19.

          Ça n'a rien d'affreux, au contraire, c'est de cette façon qu'on implémente let dans un langage permettant la programmation fonctionnelle s'il n'est pas présent de base ; on en trouvera une explication détaillée dans le premier chapitre du SICP. Comme il l'a été remarqué, let fait partie d'ecmascript 6, et sera donc dans quelques années utilisable sans polyfill, sauf à devoir supporter des vieux navigateurs.

          • [^] # Re: Fonction

            Posté par  (site web personnel) . Évalué à 3.

            Ça n'a rien d'affreux, au contraire, c'est de cette façon qu'on implémente let dans un langage permettant la programmation fonctionnelle s'il n'est pas présent de base

            Je crois que c'est ça le vrai problème. Le langage manque de fonctionnalités de bases, ce qui oblige à faire des contournements un peu tordus.

            Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 2. Dernière modification le 25 mai 2016 à 22:24.

              Ce commentaire a été supprimé par l’équipe de modération.

  • # Version 2

    Posté par  . Évalué à 2.

    En mode user friendly, avec gestion de la liste des plonkés.

    Comme je ne compte pas y passer plus de temps, c'est le moyen le plus simple que j'ai trouvé pour mettre ça à disposition: il suffit de cliquer sur le bouton raw pour que GreaseMonkey le reconnaisse et l'installe.

    https://gist.github.com/anonymous/adc571df2986ec316b50abfcf1986726

  • # Version 3

    Posté par  . Évalué à 3.

    Bon allez, optionage de la plonkabilité des comptes fermés, et suppression automatique des comptes fermés de la liste des plonkés

    https://gist.github.com/anonymous/ecf2f737c98cf722502addc62afbee68

    et basta

  • # Pour les interressés

    Posté par  . Évalué à 4.

    Pour le coup, je me suis dit que ça me permettrait de tester framagit !
    Donc la suite se trouve là: https://framagit.org/peetah/DLFPlonk

    dites moi si ça vaut le coup de faire une dépêche ou si je suis le seul utilisateur.

    merci

  • # qu'est-ce que plonk?

    Posté par  . Évalué à 2.

    Tout est dans le titre.

    merci

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.