Ah merci Gof ;)
En passant et si ça n'est pas clair, je ne veux en aucun cas faire une concurrence de quoi que ce soit avec Slint (de toute façon Slint est à des années lumière de mon machin), c'est vraiment par jeu et pour comprendre comment ça marche que je fais ça.
En fait la macro s'occupe de 99% du parsing et je la trouve assez lisible; mais je n'ai pas trouvé mieux que de faire une opération en string pour traduire ma notation $element.property en rust classique;
J'ai une méthode transform_dollar_notation(), qui essaye de faire le taf, mais comme elle est appliquée avant la macro elle doit "deviner" le type des propriété concernées, pour les cas limites (l'initialisation par callback par exemple) ou je n'arrive pas à deviner facilement le type, j'ai une notation :
$root.value = $test.testValue:f32; <= ça permet à ma méthode de déterminer que testValue doit être castée en f32.
C'est un peu dommage, parce que mon abstract value "sait" de quel type elle est, mais je ne pense pas qu'il me soit possible de faire une fonction get qui retourne des type différents, même pas une proc macro; et ça se comprend hein.
Sinon j'ai pensé à générer des structures à la fin de mon code de macro (une par noeud d'ihm) pour servir d'accesseur / setter et remplacer ma notation, avec des champs correspondants à mes propriétés, et des getter / setter.
Genre :
struct root {
value : f32
}
struct test {
testValue: f32
}
Pour pouvoir écrire :
root.value = test.testValue; <= et ça reste du rust classique au final
Mais la partie synchro avec mon engine est un peu lourdingue; soit je passe par des méthodes prégénérées (get / set; et du coup la syntaxe devient root.set_value(test.get_testValue); classique) soit je trouve le moyen de redéfinir le comportement de l'accesseur et du = en rust; soit je resynchronise toutes mes structs avec mon back à chaque boucle d’évènement.
Et je pense que je dois toujours déterminer au préalable le type de mes propriétés, et du coup je me tate à rendre leur type obligatoire à la déclaration.
Comme ça :
Node {
id: root
number value: 0.
}
Ça serait le plus simple pour s'assurer du type de mes propriétés.
J'ai bien essayé de lire le code de Slint, pour voir comment ça fonctionne, mais le code de macro doit être trop bien écrit, ça a l'air tellement simple et naturel que je ne rencontre aucunes des problématiques qui sont les miennes :)
Si tu as des idées ou des pistes concernant mes interrogations je serais ravi de les entendre, ça me ferait plaisir d'avoir l'avis de quelqu'un qui sait ce qu'il fait !
Et sinon pas de soucis, je comprend si tu as autre chose à faire, comme par exemple t'occuper de Slint ;)
[^] # Re: Voir aussi
Posté par Aldebaran (site web personnel) . En réponse au journal Rustic Markup Language : Le QML du très très pauvre !. Évalué à 2.
Ah merci Gof ;)
En passant et si ça n'est pas clair, je ne veux en aucun cas faire une concurrence de quoi que ce soit avec Slint (de toute façon Slint est à des années lumière de mon machin), c'est vraiment par jeu et pour comprendre comment ça marche que je fais ça.
En fait la macro s'occupe de 99% du parsing et je la trouve assez lisible; mais je n'ai pas trouvé mieux que de faire une opération en string pour traduire ma notation $element.property en rust classique;
J'ai une méthode transform_dollar_notation(), qui essaye de faire le taf, mais comme elle est appliquée avant la macro elle doit "deviner" le type des propriété concernées, pour les cas limites (l'initialisation par callback par exemple) ou je n'arrive pas à deviner facilement le type, j'ai une notation :
$root.value = $test.testValue:f32; <= ça permet à ma méthode de déterminer que testValue doit être castée en f32.
C'est un peu dommage, parce que mon abstract value "sait" de quel type elle est, mais je ne pense pas qu'il me soit possible de faire une fonction get qui retourne des type différents, même pas une proc macro; et ça se comprend hein.
Sinon j'ai pensé à générer des structures à la fin de mon code de macro (une par noeud d'ihm) pour servir d'accesseur / setter et remplacer ma notation, avec des champs correspondants à mes propriétés, et des getter / setter.
Genre :
struct root {
value : f32
}
struct test {
testValue: f32
}
Pour pouvoir écrire :
root.value = test.testValue; <= et ça reste du rust classique au final
Mais la partie synchro avec mon engine est un peu lourdingue; soit je passe par des méthodes prégénérées (get / set; et du coup la syntaxe devient root.set_value(test.get_testValue); classique) soit je trouve le moyen de redéfinir le comportement de l'accesseur et du = en rust; soit je resynchronise toutes mes structs avec mon back à chaque boucle d’évènement.
Et je pense que je dois toujours déterminer au préalable le type de mes propriétés, et du coup je me tate à rendre leur type obligatoire à la déclaration.
Comme ça :
Node {
id: root
number value: 0.
}
Ça serait le plus simple pour s'assurer du type de mes propriétés.
J'ai bien essayé de lire le code de Slint, pour voir comment ça fonctionne, mais le code de macro doit être trop bien écrit, ça a l'air tellement simple et naturel que je ne rencontre aucunes des problématiques qui sont les miennes :)
Si tu as des idées ou des pistes concernant mes interrogations je serais ravi de les entendre, ça me ferait plaisir d'avoir l'avis de quelqu'un qui sait ce qu'il fait !
Et sinon pas de soucis, je comprend si tu as autre chose à faire, comme par exemple t'occuper de Slint ;)