Après quelques tests avec Scalz, nous nous sommes rendus compte que le typage de certaines informations avait changé entre Debian11 et Debian12 et cela sans qu’il y ait un changement dans la database.
Question :
A-t-on une idée de tous les endroits où il va y avoir ces changements de typage ? Où faut-il juste croiser les doigts et fouiller à chaque fois qu’on aura un souci lors d’un import ?
j’ai géré le meme soucis avant l’été → lié à php8 (plus qu’à Debian 12)
ca ne touche pas juste les scénario, mais tous les objets → donc les id des cmd, eqlogic, scenario, … , les getIsEnable et surement d’autres …
il me semble que le « problème » vient du typage des fonctions côté core, qui est réellement appliqué en php8 , alors qu’en php7 ça l’était moins (!?) :
/**
*
* @param integer $_default
* @return int <------------ ici !
*/
public function getIsEnable($_default = 0) {
if ($this->isEnable == '' || !is_numeric($this->isEnable)) {
return $_default;
}
return $this->isEnable;
}
pour le souci de sagitaz, il s’agissait d’un oubli sur la partie scenario. le reste avait déjà été adapté a long time ago
Ceci dit c’est vrai qu’avant php8 (ou je ne sais quelle modif qui a enclenché le typage), les jsons api retournés par le core étaient « horribles » (imho). on trouvait du numérique au format String etc
de ce que je vois la fonction plus haut n’est pas typée non plus,cela devrait plutot ressembler à ceci
public function getIsEnable(int $_default = 0) : int { .. }
au lieu de
public function getIsEnable($_default = 0) { ... }
Et encore j’utiliserais plutot un bool, plutot qu’un int, si cétait moi, pour un getter de type « is it enabled ? »
donc je suppose que pour l’instant le core jeedom laisse php8 faire sa sauce
juste une supposition, car je ne suis pas du tout expert en php, mais à priori php a introduit la possibilité de typer à partir de php 7.4+.
Donc si jeedom a commencé à utiliser php 7.4+, et a laissé la fonctionnalité typage active (qui est surement désactivable pour migrer des projets), alors probable que certaines lib/api comme l’accès à la db renvoie à présent le type correct, et donc cela remonte dans les jsons.
Par contre cela ne type en aucun cas le core de jeedom, juste ça passe à travers et s’il y a une erreur de typage cela remonte une exception.
Si le core jeedom était typé, alors ce serait bénéfique en expérience dev (meilleure productivité en debug de bugs parfois difficiles à retracer, le dev aurait accès aux types de variables en survolant une variable ou une fonction depuis n’importe où dans son IDE, amélioration de la qualité du code et de la doc etc).
Je ne pourrais dev sans le typage imho, je passe mon chemin quand je vois un langage ou code non typé
Je pense que c’est plus ou moins ce qu’il se passe oui.
Oui mais c’est pour ca que c’est fait (de façon très incomplète) via des commentaires: ca permet d’avoir les aides dans l’ide mais sans faire exploser le tout au runtime.
Car tant que tu as des fonctions qui peuvent recevoir/renvoyer un peu tout, si on spécifie le type (des arguments de fonctions ou des valeurs de retours) bah forcément tu ramasses une exception si ca correspond pas…
Donc ajouter ca après coup ca peut être risqué, il faut le faire petit à petit en ayant bien tout vérifié
Ceci dit méfiance
Le souci de sagitaz était rapide à debug, et visible surtout.
On pourrait tout à fait imaginer, pour reprendre la fonction citée plus haut , que dans certains plugins il y ait des choses du style (il y a probablement des fonctions plus pertinentes pour l’exemple)
if ( ... -> getIsEnable() === '1')
J’ai déjà vu ce genre de choses dans des plugins, mais je n’ai pas d’exemples en tete.
Et dans ce cas, il n’y aura probablement pas d’exception, mais le code ne fonctionnera plus, silencieusement, puisqu’à présent c’est du int et non du String.
Et en fonction de la taille du business logic derrière, ça peut prendre plus ou moins de temps à trouver la ligne coupable.
Donc laisser activer le typage dans php, mais coté core que cela reste non typé, à voir si c’était une vraie bonne idée. Perso je suis plutot tout ou rien, plutot que de le faire petit à petit et de déranger les devs tiers à chaque fois qu’il y aura une fonction qui passera en typé, il vaut mieux prendre son temps, tout typer, et ensuite notifier les devs qu’il y a des breaking changes, et que c’est pour le meilleur
Je me permet d’intervenir dans la conversation car pour le plugin cozytouch pour lequel j’ai déjà fait des PR sur le github de l’auteur pour améliorer la compatibilité php 8, j’ai beaucoup de mal à localiser les lignes fautives. Par exemple si quelqu’un poste un message disant qu’il a une erreur du style
Unsupported operand types: string - int
Comment améliorez-vous les messages de debug pour avoir davantage de précisions sans retoucher tout le code du plugin ?
Je pensais que cela avait été fait récemment au niveau du core mais il semble que non.
je vais laisser les autres répondre, car je ne suis pas du tout expert php et core jeedom
Je n’utilise que des langages typés et compilés, donc je ne peux pas avoir d’erreurs de typage pendant le runtime, l’IDE me mettrait une ligne rouge en amont et le compilateur m’empecherait de build le projet
Oui mais dans le cas précis de cozytouch c’est insuffisant car par exemple récemment c’était un problème qui n’arrivait qu’avec les chauffe eau et je ne peux tester qu’avec les appareils que je possède (je n’ai qu’un radiateur sèche serviettes) et donc moi sur mon jeedom de test en debian 12 je n’avais pas les messages d’erreur qu’un utilisateur a signalé donc j’ai dû faire une correction en aveugle et lui demander de tester si çà corrigeait son problème.
J’avoue que quand j’ai commencé à programmer pour Jeedom cet absence de typage m’a pas mal perturbé car le programme précédent auquel j’ai collaboré (Moodle) tout était typé et les intégrateurs n’aurait jamais laissé passer un de mes commits si j’avais oublié de typer correctement. mais bon je me suis adapté.
Bonjour,
Le core marche correctement en debian 12, le changement de typage vient de php 8 lui meme (pas du core) ou maintenant php respect correctement le typage des json. Dans 99% des cas le core s’en fou car il gere lui meme le typage quand yen a besoin avec du cast. Il y a quelques soucis dans les plugins type script et virtuel car les valeurs viennent de l’utilisateur et la le typage ne peut etre connu correctement mais dès qu’on me le remonte je corrige dans la journée.
