OK
AJAX error!

Les forumsGrammalecteEssayer de mieux séparer code / data

Essayer de mieux séparer code / data

Bonjour,

J'ai vu que tu faisais pas mal de modification actuellement, je me demandais s'il n'étais pas possible en même temps d'essayer de mieux séparé le code et la data.

Je m'explique par exemple dans graphspell le fichier "char_player.ext" contient beaucoup de constantes et que 2 ou 3 fonctions et est essentiellement utilisé dans "str_transform.ext", pourquoi ne pas mettre mettre toutes ses constantes dans un json et puis regroupé les fonctions dans "str_transform.ext" (se que j'ai fait pour le portage rust) ? L'avantage c'est de diminuer l'indépendance du code avec la langue, et puis de pouvoir ajusté certaine choses plus facilement.

Je pense que dans grammalecte le "gc_rules_graph.ext" pourrait être un json il ne contient que des constantes...

Pour évité qu'il y ait trop de json certain doivent pouvoir être regroupé en un seul : conj_data - locutions_data - mfsp_data => fr.json par exemple.

Les avantages c'est que le json peut être utilisé "facilement" dans tous les langages, de plus ça pourrait éventuellement permettre des mises à jour intermédiaires qui ne modifie que la data.

Sinon le fichier généré "gc_functions.ext" génère pas mal de fonction dont leur corps sont les mêmes (qui font exactement la même chose), n'est-il pas possible de diminuer leur nombre (genre que le nom de la fonction est le md5 du corps de la fonction) ?
le 26 novembre 2020 à 11:50

Je m'explique par exemple dans graphspell le fichier "char_player.ext" contient beaucoup de constantes et que 2 ou 3 fonctions et est essentiellement utilisé dans "str_transform.ext", pourquoi ne pas mettre mettre toutes ses constantes dans un json et puis regroupé les fonctions dans "str_transform.ext" (se que j'ai fait pour le portage rust) ? L'avantage c'est de diminuer l'indépendance du code avec la langue, et puis de pouvoir ajusté certaine choses plus facilement.


C’est justement pour séparer les données et le code que ces données ne sont pas incluses dans str_transform. Je préfère aussi éviter de trop segmenter le code en divers éléments. Le processus de build est déjà assez complexe.

Je pense que dans grammalecte le "gc_rules_graph.ext" pourrait être un json il ne contient que des constantes...


Non.
Les données de ce fichier sont totalement dépendantes du code. Quand une règle appelle une fonction précise, c’est totalement dépendant du code auquel ces règles font référence. Il n’y a pas d’indépendance des données. Tu ne peux pas prendre ces données d’une version de Grammalecte et les coller dans une autre version. Ça ne fonctionnera pas.
Autrement dit, ces “données” sont partie intégrante du code, elles ne sont pas substituables, et elles ne sont constantes que sur une build. À chaque build ces données changent. Rien à voir avec le dictionnaire ou d’autres données, qui sont, elles, beaucoup plus stables, puisqu’elles ne changent presque jamais, elles sont seulement complétées.

Pour évité qu'il y ait trop de json certain doivent pouvoir être regroupé en un seul : conj_data - locutions_data - mfsp_data => fr.json par exemple.


Quand on veut éviter qu’il y ait trop de fichiers annexes à charger, le mieux reste de ne pas en créer d’autres…
“locutions_data” n’existe plus. Quant aux deux autres, non, elles resteront séparées, car je ne veux pas que le conjugueur charge en mémoire des données inutiles.

Les avantages c'est que le json peut être utilisé "facilement" dans tous les langages, de plus ça pourrait éventuellement permettre des mises à jour intermédiaires qui ne modifie que la data.


Ça n’est probablement jamais arrivé qu’il n’y ait que les données modifiées, et puisqu’il n’y a aucune autre procédure de mise à jour que celles existantes, ça revient au même. Dans tous les cas, il faut télécharger l’extension entière.

Peut-être y a-t-il d’autres données qui mériteraient d’être sorties du code, mais je suis dubitatif.
Ce n’est pas aussi commode de charger un fichier JSON que d’importer un fichier de code. Et ça n’apporte strictement rien aux utilisateurs, qui se foutent totalement de la manière dont sont gérées les données.

Sinon le fichier généré "gc_functions.ext" génère pas mal de fonction dont leur corps sont les mêmes (qui font exactement la même chose), n'est-il pas possible de diminuer leur nombre (genre que le nom de la fonction est le md5 du corps de la fonction) ?


Beaucoup de fonctions semblent être identiques, mais ne sont pas identiques, il faut être très attentif.
Le processus de build éradique déjà les fonctions identiques, mais seulement les fonctions identiques créées par un même graphe.
Donc, s’il y a des fonctions identiques, ce ne sont que les fonctions générées par les graphes différents. Il y en a certainement, mais probablement pas tant que ça.

Autrefois, ces doublons étaient tous éradiqués, mais depuis que le processus de build utilise plusieurs processus pour construire les graphes (un pour chaque graphe), les graphes ne savent plus quelles fonctions ont créé les autres graphes. On pourrait éventuellement refaire du tri après, mais je ne pense pas que ça changerait grand-chose.

Quant au MD5 pour nommer les fonctions, ça allonge les noms de fonction pour rien, tu perdras la place que tu veux gagner : un numéro unique suffit.
le 28 novembre 2020 à 08:41

Notification par e-mail    0