Optimize file generation and overloading #281
Conversation
jocgir
commented
Dec 3, 2024
jocgir
commented
- Fix file generation to ensure that we don't create useless files or rename files that have not been modified
- Add a function Diff on String to be able to view the diff between two strings
- Remove some spelling errors
- Fix file generation to ensure that we don't create useless files or rename files that have not been modified - Add a function Diff on String to be able to view the diff between two strings - Remove some spelling errors
template/template_handler.go
Outdated
| fmt.Println("error", err) | ||
| InternalLog.Debugf("%s(%d): Execution error %v", th.Filename, th.Try, err) |
There was a problem hiding this comment.
c'est un doublon dans les logs si debug est on?
| @@ -279,5 +278,6 @@ func (t *Template) processContentInternal(originalContent, source string, origin | |||
| } | |||
| result = s.Str() | |||
| } | |||
| changed = result != originalContent | |||
There was a problem hiding this comment.
J'imagine que c'est setté pour les defer... en particulier le premier?
Avec 2 defers (un des 2 va setter changed à false) ça feel comme un code smell, aggravé par la longueur de la fonction. Je ne suis pas certain comment améliorer cela mais j'ai l'impression que l'ordre d'invocation des defers est important et c'est facile à casser?
There was a problem hiding this comment.
Je suis d'accord pour ce qui est de la longueur de la fonction. Ça serait à améliorer.
Mais non, je ne crois pas que ça casse la fonction. Les 2 defers sont exécutés dans des contexts différents. Dans le premier cas, c'est si on applique un manual handler qui apporte une modification après coup. Il est exécuté seulement après l'évaluation de la fonction.
Dans le second defer, le but est de générer une erreur si des variables ne sont pas définies (selon le mode d'opération de gotemplate). Si on rapporte une erreur, alors, on ne considère pas qu'il y a eu des changements.
There was a problem hiding this comment.
Et non, la variable changed n'est pas settée pour les defers, c'est vraiment le retour de la fonction. Quand on utilise des named return, on n'a pas besoin de retourner les variables sur le return.
Et les defers peuvent également changer le résultat de la fonction (après le return).
There was a problem hiding this comment.
aaah les maudits named return... Belle invention du diable.
There was a problem hiding this comment.
Reste que là, on a juste 1 defer qui peut changer le changed. Si on en avait 2, ça commencerait à être stressant :P
