[Ludique] Défis code en un tweet

Version imprimable

Voir 40 message(s) de cette discussion en une page

30/09/2015, 10h44
Lcf.vs

Oui, juste...

En revanche, dans mes dernières versions, l'arité est réduite de 1, pour permettre curryN(0, "".substring, "hello world!", 6, 11)Car bon, lui disant qu'il y a 0 appels, avoir un appel après, spécifiant les params, j'trouvais ça étrange...

Après, c'est juste un point de vue. ;)
30/09/2015, 16h15
SylvainPV

Moi c'est le fait que tu veuilles un curry à arité zéro que je trouve étrange :D En fait, c'est juste notre manière de compter qui diffère. Je ne compte pas les appels pour passer l'arité et la fonction à curryfier. Un curry à deux temps transforme une fonction F en une fonction G où il faut passer les arguments en deux appels : F(x,y) == G(x)(y) ; du coup avec cette définition, un curry zéro signifierait qu'on ne passe pas du tout les paramètres, ce qui est un peu bizarre tu en conviendras ^^
30/09/2015, 18h44
Lcf.vs

Oui, oui, je comprends bien... pour ça que j'm'en suis d'abord tenu à tes contraintes...

Ensuite, repensant à la suggestion de Watilin, j'me suis dit qu'on devait pouvoir trouver un compromis entre les deux et j'en ai fait ma propre version. :)
30/09/2015, 19h18
Watilin

Et tu as bien trouvé puisqu'on avait tous les deux oublié le bind ;)
30/09/2015, 20h59
SylvainPV

J'avais pensé à un moyen de ne pas avoir à préciser l'arité, qui était d'appeler la fonction sans aucun argument pour savoir quand "fermer" le currying et appeler la fonction. Mais ça ne marche pas avec la solution à base de bind, et d'une manière générale je ne suis pas sûr que ce soit une bonne idée d'avoir une arité indéfinie.

:cfou: :bravo: à tous !

Il m'a fallu du temps pour tester, disséquer et comprendre (j'espère :aie:) tous vos codes. Je ne sais pas si c'est l'âge ou la maladie, mais j'ai de la peine à suivre.

Mention très bien pour @SylvainPV :king:

Pour comprendre la recette du curry, j'ai dû l'écrire de cette manière :

Code:

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
31
32
<script src="https://google.github.io/traceur-compiler/bin/traceur.js"></script>
<script src="https://google.github.io/traceur-compiler/src/bootstrap.js"></script>
<script type="module">
 
  let
    curryN = ( n ) => {
      return (
        F,
        s = [],
        R = ( ...args ) => {
 
          console.log( F, s, args );
 
          return ( s.push( ...args ), --n ? R : F.call( ...s ) );
        }
      ) => {
        return R;
      }
    };
 
  console.log( 
    curryN( 3 )( "".substring )( "hello world!" )( 6 )( 11 ) === "world"
  );
 
  /*
  substring() { [native code] } [] ["hello world!"]
  substring() { [native code] } ["hello world!"] [6]
  substring() { [native code] } ["hello world!", 6] [11]
  true
  */
 
</script>

01/10/2015, 00h54
SylvainPV

Pour autant que je puisse en juger, on a plusieurs très bons golfeurs ici. Ce n'est pas un sport très courant donc je suis content que ce topic ait autant de succès et qu'il soit up de temps à autre :) Je ne m'attendais pas à ça lorsque je l'ai ouvert.

Pas d'inquiétudes si tu n'arrives pas à suivre, c'est tout à fait normal :mrgreen: La minification du code complique énormément sa compréhension, le seul moyen de comprendre est d'indenter et de renommer les variables. Moi-même je ne comprends plus mes propres codes postés ici l'année dernière.
01/10/2015, 13h27
Watilin

En parlant de golf, je suis tombé par hasard là-dessus il y a quelques jours, et si ça peut te rassurer danielhagnoul, nous avons l'air de petits joueurs à l'esprit lamentablement sain à côté de ces gens :mrgreen:

N'empêche, j'préfère tout de même mon chain, qui porte certainement d'autres noms, au curry...

Code:

var c,chain=c=(i,a,r)=>(f,...p)=>(r=>a>1?c(r,a-1):r)(f.call(i,...p))

Ou, pour Daniel :troll: :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 var chain; chain = function (instance, arity) { return function (fct, ...args) { var result; result = fct.call(instance, ...args); return arity > 1 ? chain(result, arity - 1) : result; }; };

01/10/2015, 22h49
SylvainPV
Je ne comprends pas pourquoi tu utilises un argument d'arité avec une fonction de chaînage. La curryfication permet de produire des fonctions intermédiaires réutilisables, mais dans le cas du chaînage de méthodes, ça n'a aucun intérêt vu que les exécutions des fonctions auront toujours le même résultat. Autant garder directement une référence au résultat intermédiaire. Aussi, pourquoi invoquer toutes les fonctions sur la même instance, d'autant qu'elle est cachée en fermeture ? Typiquement, le chaînage de méthodes est très utilisé en prog fonctionnelle où l'on aime travailler avec des données immuables. Avec cette fonction, c'est impossible et on ne peut ni filtrer, ni étendre, ni modifier le contexte comme on le ferait avec jQuery, underscore ou même de simples Array ou Promise.

Généralement, le chaînage de méthodes suit plutôt cette approche:
Code:

1 2 3 4 5 6 7 // Make a method chainable chainable: function(method) { return function() { var ret = method.apply(this, arguments) return ret === undefined? this : ret; } }
tiré de http://leaverou.github.io/chainvas/ de Lea Verou ; c'est la même approche utilisée par jQuery, underscore et bien d'autres bibliothèques
01/10/2015, 23h23
Lcf.vs
~~L'arité sert, comme pour le curryN, à savoir quand retourner la valeur finale, c'est tout, sinon, on retourne une fonction.~~

Tu as raison, on peut aisément s'en débarrasser, en fait...

Code:

var c,chain=c=i=>(f,...p)=>f?c(f.call(i,...p)):i;

Soit :
Code:

1 2 3 4 5 6 7 8 9 var chain; chain = function (instance) { return function (fct, ...args) { return fct ? chain(fct.call(instance, ...args)) : instance; }; };
Il y a tout de même deux différences avec ton code, il n'y a pas de référence à this, dans le mien... je n'aime pas les this, ça se minifie pas et ça marche pas avec les arrow-functions.

Par contre, si, on peut tout à fait filtrer avec et, pour des traitements récurrents, comme une réponse en AJAX, sur un chat, par exemple, c'est super pratique, et sans besoin de binding...

Exemple

Sais pas vous, mais j'adore sa lisibilité :P
02/10/2015, 10h35
SylvainPV

Oui c'est déjà mieux comme ça. Mais ça fonctionne uniquement parce que tu utilises déjà des API chaînables: replace, substring, split etc... Si tu utilises des méthodes non chaînables comme celle du prototype Date par exemple, tu ne pourras pas réutiliser la valeur de retour de la même manière. C'est justement le but de la lib de Lea: transformer les fonctions mutables en fonctions chaînables. Elle l'a appliqué sur les API du DOM et des Canvas à cet effet.
02/10/2015, 12h30
Watilin

Citation:

Envoyé par Lcf.vs

Sais pas vous, mais j'adore sa lisibilité :P

En effet c'est lisible, mais c'est plutôt rigide : en fait tu mets en variables des appels de fonctions avec un certain nombre de paramètres « pré-passés ». Donc au final tu ne fais qu'augmenter la taille du code pour avoir un syntaxe d'appel différente à la fin. Ou alors j'ai raté quelque chose.

Ce qui est intéressant, c'est qu'on voit bien ici une conséquence de la venue de l'opérateur spread : il a rendu ténue la frontière entre les tableaux et les listes d'arguments.
02/10/2015, 13h56
Lcf.vs
Moui mais, bon, moi, ce que j'y aime bien, c'est la séparation entre les instructions de traitement... et le traitement, lui-même...

Concernant le poids du code, je pense qu'au contraire, ça peut sacrément le réduire, de par la réutilisation des instructions de traitement.

En effet, sur des appels directs de méthodes, tu ne sais quasiment pas les minifier, à moins de prévoir des fonctions qui seront réutilisables, pour chaque combinaison de cas.

Moi, le spread, j'adore... en revanche, je trouve le rest parameter un peu trop limité...

À mon sens, on devrait pouvoir le placer n'importe où, dans la liste d'arguments... avec pour seule règle, son unicité.

Genre :
Code:

1 2 3 void function (a, ...b, c) { // code }(1, 2, 3, 4);
Allez, pour le fun, j'ai fait une grosse révision de mon chain, il tient malheureusement plus dans un tweet mais, bon...

Code:

var c,chain=c=i=>(f,...a)=>((t=typeof f)=>t==='function'?(f.call(i,...a),c(i)):t==='string'?(i[f](...a),c(i)):t==='object'?(a=[...f,...a],c(a.shift().call(i,...a))):i)();

Démo

Et la version optimisée (en perfs) :

Code:

var chain=c=>(c=((e,t)=>i=>(f,...a)=>(t=typeof f,t in e)?e[t](i,f,a):i)({function:(i,f,a)=>(f.call(i,...a),c(i)),string:(i,f,a)=>(i[f](...a),c(i)),object:(i,f,a)=>c(f.shift().call(i,...f,...a))}))()

Démo
20/10/2016, 16h41
Watilin

Coucou, ça fait un an, allez, nouveau défi ! :D

L’objectif est, étant donné un élément DOM positionné, de connaître sa position verticale « réelle », c’est-à-dire la somme de son offsetTop et de tous ceux de ses offsetParents. Nous aurons donc une fonction qui prend en paramètre un élément DOM et qui retourne un entier. Syntaxe ES2015 autorisée, évidemment.

J’ai une solution qui fait exactement 100 caractères :)
20/10/2016, 17h30
SylvainPV

Code:

getOffsetTop = e=>scrollY+e.getBoundingClientRect().top
20/10/2016, 18h38
Watilin

C’est trop simple ! :P
Moi ce qui m’intéressait c’est le processus de remontée de parent en parent. Cette conversation avec patricktoulon m’a rappelé que ce n’est pas quelque chose de complètement trivial. Et encore moins quand on est limité en espace…

Mais en tout cas, merci pour ta solution que je ne connaissais pas ;)
20/10/2016, 18h59
NoSmoking

Je salut le retour...
en 3

F12

:dehors:
20/10/2016, 20h39
SylvainPV

Concernant ta discussion avec patrick, je pense immédiatement à la méthode closest de DOM4 : https://dom.spec.whatwg.org/#dom-element-closest

Le polyfill est assez simple: https://plainjs.com/javascript/trave...y-selector-39/
20/10/2016, 20h44
Watilin

Ok mais alors il faut compter les clics ! (Edit: je répondais à NoSmoking)

Bon hey, je me rends compte que j’avais la tête dans le truc et que je n’ai pas vu la solution la plus simple. Sinon je descends à 60 caractères.

Alors je vais rajouter une contrainte : il faut utiliser yield ;)

Voir 40 message(s) de cette discussion en une page