Voui j'ai vu.
Je te remercie d'ailleurs de ta relecture. Je porte les corrections demain. :mouarf:
Version imprimable
Je dois avouer que je comprends vachement mieux les schémas avec les explications :D
Bon, j'attendais d'avoir lu les 2 articles pour te faire un retour (ton article sur les foncteurs et l'article sur Scala.React), mais ça traine un peu (pas assez de temps dans une journée :aie:).
Cette façon de programmer est vraiment intéressante. Ça m'a bien épaté.
Il faut que je jette un oeil en profondeur sur tout ça, mais t'as déjà fait un gros boulot ! :ccool:
Petite remarque subsidiaire, comme tu as changé ton bitbucket, ça serait pas mal, soit de mettre à jour les liens dans les posts précédents, soit de faire un post récapitulatif. C'est toujours frustrant de se manger un 404 quand on clique sur un lien :?
Voilà, à+
Gueritarish
Bonjour Gueritarish.
Pour le lien, je te donne raison, mais je ne parviens pas à éditer un poste ultérieur.
Voici donc la nouvelle address Bitbucket
Hier, en essayant d'expliquer la FRP à un collègue, je me suis rendu compte que j'était confus, et qu'en fait c'est très simple.
Prenons l'exemple suivant en impératif classique :
Montrez ça à n'importe quel non développeur (mon gamin de 12 ans par exemple) et il vous rie au nez :Code:
1
2
3
4
5
6
7
8
9 int a = 0; int b = 0; int sum = a + b; System.out.println (sum); // 0, jusqu'ici tout va bien a = 10; b = 10; System.out.println (sum); // 0, ça vas toujours ?
"Hey papa, tu ne sais donc pas calculé : 10 + 10 ça fait 20 !!!!"
En programmation Réactive le même programme pourrait donner :
sum étant égale à a + b, si a ou b change son résultat devrait changé.Code:
1
2
3
4
5
6
7
8
9 int a = 0; int b = 0; int sum = a + b; System.out.println (sum); // 0, jusqu'ici tout va bien a = 10; b = 10; System.out.println (sum); // 20, ça vas mieux !
En fait, ça fait juste 50 ans que nous, pauvres développeurs, nous somme habituer à ce que la variable (pas si variable que ça du coup) ne change pas si ses opérandes venaient à être changés. En fait on c'est habituer à ce que, dans le temps, sum = a + b ne soit plus vérifiable si l'une de ses opérande était altérée.
Maintenant imaginons que notre ordinateur soit lui aussi réactif. Que ses états puissent changés dans le temps. Ce qui est le cas du curseur de la souris, de la touche du clavier et même du temps lui même.
Imaginons, avec un tel système que nous voulions écrire dans un label la position de notre souris :
Les variables posX et posY vont varier dans le temps de même que x et y. Cela vas provoquer la variation de la variable text.Code:
1
2
3
4
5
6 int x = Mouse.posX; int y = Mouse.posY; String text = "La position de la souris est (" + x + ", " + y + "); myLabel.setText (text);
Plus besoin de gérer un évènement sur la souris, c'est le système de donnée qui c'en charge.
C'est un peu ce que j'aimerai obtenir à terme dans mon ti langage AL.
En attendant j'aimerai déjà l'intégré à Java. D'ou ma petite librairie.
Maintenant un moyen d'intégrer cela dans un langage dont les états ne peuvent pas varier, est d'utiliser la FRP Functional Reactive Programming qui est une adaptation de cette idée dans les langages fonctionnels comme Haskell et un dialecte dérivé ELM.
Voilà, sinon une petite démonstration des capacités de ma tite librairie adapté aux jeux vidéos : [ame="http://www.youtube.com/watch?v=-tYmfA1qqnw"]React4J - game developpment[/ame]
Remarquez comme lorsque la fenêtre est redimensionné, tout reprend sa place.
La positions des étoiles est un ratio sur la taille de la fenêtre. Si elle varie, ce ratio est automatiquement recalculé.
Salut,
Juste un petit post pour te dire que je trouve ton travail remarquable.
Et même si je dois bien avouer ne pas avoir encore tout compris, les perspectives qu'offre ta librairie ont l'air très prometteuses.
Je vais donc suivre ton travail avec intérêt :ccool::ccool:
@+
Merci nico, c'est motivant ! :ccool:
Désolé je connais pas :? Dans le domaine de la programmation concurrente et distribuée, je sais qu'Erlang est très réputé mais je ne m'y suis pas encore essayé.
En fait je vois pas trop en quoi c'est différent d'Observer et ses Listener. React devrait plutôt s'appeler Dispatcher. Regarde du côté de java.awt.EventQueue et java.awt.EventDispatchThread.
Une construction du type or(function, onPressed(), onMove()) m'aurait paru plus compréhensible.
Je te propose : or/merge, and/join, after, before.
Et donc le toVar sert à ?
C'est quoi leur type ?
De ce que j'en comprends ca affiche "button [pressed|released] ( x=?, y=?)", je trouve pas ca du tout expressif par rapport à
non ?Code:
1
2
3
4 merge( (Boolean buttonStatus, Point location) -> return "button " + (buttonStatus ? "pressed" : "released") + "( x=" + location.x + ", y=" + location.y + ")"), onButton1(), onMove());
Ok, je comprends l'idée. D'ailleurs je pense que tu apprécieras la syntaxe de Ceylon :
Code:
1
2
3 Integer a = 0; Integer b = 0; Integer sum { return a + b };
+1
Par ailleurs, ca serait bien de pouvoir consulter la javadoc en ligne et de pouvoir télécharger les sources sous forme d'archive. Ou alors les inclure dans le jar exécutable. Pas trop envie d'installer Mercurial et cloner le dépôt pour récupérer les sources correspondants aux binaires.
Peu-t-on abonner un listener à sum en ceylon ?
Si c'est possible sans télécharger bitbucket (mais comme vous j'ai mis du temps pour trouver)
Va dans download, onglet tags il y a un petit lien zip à coté du tag tip.
Allez je suis bon avec toi, voici le lien : https://bitbucket.org/yann_caron/react4j/get/tip.zip
Normalement la javadoc et les testes unitaires sont dedans. Tout n'est pas encore tout à fait terminé hein !
Pour le reste de tes remarques j'y reflechis et te redit.
Je vais sans doute revoir les noms, c'est une bonne idée. :ccool::ccool::ccool::ccool:
Pour les termes, je t'invite fortement à consulter le jargon BPMN et SysML qui traitent justement de "signaux" et de "processus".
EDIT: En y repesant le diagramme d'activité d'UML définit déjà ses concepts : decision/merge et fork/join.
Je suis nul en choix de noms. Donc je prend.
En effet cette implémentation de FRP est dite discrete (event driven) d'autre sont en temps continue (en échantillonnant)
Je retiens les noms
Mais que fait-on de TimeReact.once, TimeReact.every, TimeReact.framePerSecond et TimeReact.randomly ? Les noms conviennent il ?
Je prend after et before. Merge et Sync me plaisent bien.
Passer d'un signal (qui n'as pas de valeur, ce sont des instants) à une variable (qui à une valeur tout au long du temps et donc une à son initialisation)
J'ai mise le wiki à jours avec des joli schemats ICI
Signal<Integer>
Oui c'est dejà le cas (mais c'est moins fonctionnel et ça n'illustre pas les fonctions d'ordre supérieures) :
Merci encore pour tes remarques :ccool::ccool::ccool:Code:
1
2
3
4
5
6
7
8
9 final Var<Integer> x = MouseReact.onMoveX().toVar(0); // mouse x reactive position final Var<Integer> y = MouseReact.onMoveY().toVar(0); // mouse y reactive position Operation<String> text = Operation.mergeOperation(() -> "mouse position (" + x.getValue() + ", " + y.getValue() + ")", x, y); // react text = "mouse position (" react x ", " react y ")" text.subscribe((String textPosition) -> { System.out.println(textPosition); });
Je comprends j'ai le même soucis ^^
Ne sachant pas exactement à quoi correspondent "once" et "randomly", je ne me prononcerais pas. Sinon "every" c'est très bien et "framePerSecond", je le remplacerait peut-être "atRate" et toujours une notion de TimeUnit. Par exemple, [CODEINLINE=Java]TimeReact.atRate(2, TimeUnit.MINUTES)[/CODELINE] pour dire deux fois par minutes.
Affreux d'autant que c'est super important, ça impact directement la lisibilité du code
En fait TimeReact.once lance un thread qui s'execute qu'un fois au bout d'un moment
TimeReact.randomly, lange un thread et déclenche l'émission à des intervales aléatoires (bornées)
nb : L'idée de timeunit est bonne. Je vais regarder.
Il faut aussi que je profil un peu le tout histoire de voir si ça ne génère pas trop d'objet (un peu quand même ! Pas bon pour Android tout ça !)
Rhaaaa mince !!!! Ca ressemble étrangement !
http://docs.oracle.com/javafx/2/bind...ub-binding.htm
Pire encore, c'est carrément ça : https://github.com/Netflix/RxJava/wi...ng-Observables
J'avais vu qu'il existant cette lib, mais je n'avait pas trouvé sa page wiki.
C'est chose faite maintenant. Suis blazzzzéeuuu :cry::cry::cry::cry: ....
'fin bref, je me serais bien amusé ^_^
Ca n'empeche pas de faire un article pour présenter le concept. Et tout le travail fournit permet de bien comprendre le concept et l'étendu de sa complexité en termes d'implémentation.
Dans le cadre d'un article, ca permet de présenter une implémentation avec la bonne direction vu que tu connais les pièges.
Bref, je pense pas que ce travail était une perte de temps.
Tout à fait !
J'ai un peu fait joujou avec RxJava cet aprèm, c'est trait pour trait ce que j'ai fait. En mieux évidemment! La gestion des émission par subscriber est super bien pensé et les 3 évènements distincts next / finish et error permettent d'entrevoir des trucs sympa.
Le seul truc qui leur manque d'après ce que j'ai vu, c'est des "sujets" comme ils les appellent qui génère des évènements en fonction des évènements systèmes comme clock, mouse, keyboard. Eux sembles ce focaliser sur des listes et des suite d'évènements finis.
Je me suis amusé à créer un timer, ça joue nickel.
Il y a même un moyen de faire les opérations que j'ai cités dans mon article.
Leur approche est même bien meilleur que celle de java avec les bindings qui j'ai cité 3 postes plus haut.
Bref, je continue mon investigation.
Je suis en train de regarder pour coller cette librairie avec une librairie de jeux vidéos. Pour reproduire mon petit space invader maison. :ccool:
L'idée serait à terme de faire du reactive game programming.