Techniquement, tous ces toolkits sont en go. Ca veut dire que tu as un GC et si tu remplace le contenu d'un conteneur par un autre arbre de widget, celui-ci fera exactement la meme chose qu'en react. Maintenant, je ne pense pas que ce soit un bon pattern pour l'usage de ces API, car cela implique de creer/detruire pas mal d'objet.
Meme avec un systeme optimise, cela a un cout qui impact les performances. Dans ton exemple, c'est probablement negliegable voir meme pas mesurable. Mais comme pattern generaliste, cela a clairement un impact sur les performances. La premiere limite d'un systeme aujourd'hui, c'est sa bande passante memoire. Creer/detruire/acceder de la memoire a tout bout de champs pour pas grand chose a un impact sur les performances non negligeable.
Ainsi une API dans laquel on va juste rendre invisible explicitement le button sera plus efficace qu'une dans laquelle on va soit traverser un arbre ou parser une commande pour decider de rendre invisible ou detruire un button. Je trouve aussi que cela a tendance a mixer code definissant l'interface et logique du programme, cela veut dire que collaborer avec un designer n'est pas forcement trivial. Je pense qu'on peut faire mieux que ca.
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 4.
Techniquement, tous ces toolkits sont en go. Ca veut dire que tu as un GC et si tu remplace le contenu d'un conteneur par un autre arbre de widget, celui-ci fera exactement la meme chose qu'en react. Maintenant, je ne pense pas que ce soit un bon pattern pour l'usage de ces API, car cela implique de creer/detruire pas mal d'objet.
Meme avec un systeme optimise, cela a un cout qui impact les performances. Dans ton exemple, c'est probablement negliegable voir meme pas mesurable. Mais comme pattern generaliste, cela a clairement un impact sur les performances. La premiere limite d'un systeme aujourd'hui, c'est sa bande passante memoire. Creer/detruire/acceder de la memoire a tout bout de champs pour pas grand chose a un impact sur les performances non negligeable.
Ainsi une API dans laquel on va juste rendre invisible explicitement le button sera plus efficace qu'une dans laquelle on va soit traverser un arbre ou parser une commande pour decider de rendre invisible ou detruire un button. Je trouve aussi que cela a tendance a mixer code definissant l'interface et logique du programme, cela veut dire que collaborer avec un designer n'est pas forcement trivial. Je pense qu'on peut faire mieux que ca.