Update log.class.php

[zoic21]

Fix https://community.jeedom.com/t/cannot-install-jeedom-cancelling/140475/2

Description

Suggested changelog entry

Related issues/external references

Fixes #

Types of changes

• Bug fix (non-breaking change which fixes)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
  • This change is only breaking for integrators, not for external standards or end-users.
• Documentation improvement

PR checklist

• I have checked there is no other PR open for the same change.
• I have read the [La ligne directrice pour contribuer à ce projet / Contribution guidelines for this project).
• I grant the project the right to include and distribute the code under the GNU.
• I have added tests to cover my changes.
• I have verified that the code complies with the projects coding standards.
• [Required for new sniffs] I have added MD documentation for the sniff.

[kwizer15]

Pourquoi ces "aller-retours" sur cette signature ?
Si c’est problématique, on peut rendre la class log indépendante de la PSR et faire quelque chose dans ce genre : https://github.com/kwizer15/core/pull/2/files (ne pas tenir compte des modifs sur log.class.php)

[zoic21]

Car le changement était pour rendre la declaration identique a PSR mais qui en fonction des versions de PHP change ce qui pose soucis. Et malheureusement non on peut pas etre independant de PSR car certain plugin s'appuient dessus

[kwizer15]

Ok, il me semblait que dans la version 1.1.4 de psr/log il y avait bien le string mais ce n’est effectivement pas le cas.
Je te propose toutefois de rester pleinement compatible avec la psr en respectant strictement la signature de l’interface :

public function log($level, $message, array $context = array());

sans le : void à la fin. Je suis conscient que ce n’est en rien impactant mais ca permettrait de rester souple vis-à-vis des plugins qui pourraient éventuellement étendre cette classe et rester au maximum cohérent vis-à-vis de l’interface originale.

[zoic21]

Effective le void n'est pas utile non plus je viens de le retirer

[Sekiro-kost]

PSR-3 : pour message, a string or an object implementing __toString()

Every method accepts a string as the message, or an object with a __toString() method. Implementors MAY have special handling for the passed objects. If that is not the case, implementors MUST cast it to a string

Il serait donc judicieux pour encore plus de fiabilité et prévenir d'erreur, de caster le $message :

public function log($level, $message, array $context = array()): {
log::add($this->_log_name, $level, (string) $message);
}

[kwizer15]

Je propose de merger en l'état afin de corriger le problème rapidement et de faire une autre pr pour améliorer l'implèm.
Pour etre tres carré, on pourrait, au préalable, vérifier si le parametre est "stringable" via un is_scalar et un method_exists($object, "__toString"). Dans le cas contraire, soit logger un message spécifique, soit renvoyer une exception.