Deprecate log::add methode

[kwizer15]

Description

Faisant suite la PR #2892
Cette PR déprécié la méthode statique log::add() au profit de la méthode standardisée PSR-3 log::getLogger()->log().

Changements

• Ajout de l'annotation @deprecated sur la méthode add()
• Ajout d'un message d'avertissement de dépréciation via trigger_error()
• Redirection de la méthode add() vers getLogger()->log()

Migration

Pour mettre à jour votre code, remplacez :

log::add($log, $type, $message, $logicalId);

par :

log::getLogger($log)->log($type, $message, ['logicalId' => $logicalId]);

Suggested changelog entry

Deprecate: mark log::add() method as deprecated

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.

[Mips2648]

Salut,

Quel est l'intérêt, l'avantage ?

Ça ne me paraît pas dingue de forcer les changements dans tous le core et surtout tous les plugins.

C'est une écriture plus courte aussi donc plus simple à l'usage.

Je ne suis pas en faveur de ce PR.

[kwizer15]

En fait je comprend pas l’intérêt de ta PR si l'objectif n'est pas de migrer vers la PSR-3 (ce qui serait une très bonne chose).

On ne force rien pour le moment, la migration peut être progressive, et c'est bien tout l'intérêt ici. Ca reste fonctionnel tant qu’on ne supprime pas la méthode add(). Cette modication devrait être faite sur le passage a une version majeur.
La version majeur indiquée dans la PR (5.0.0) est arbitraire et modifiable même à postériori.

La migration du core n'a pas été faite ici pour éviter de surcharger la PR inutilement.

J'ai volontairement ajouter un trigger_error pour indiquer aux développeurs le futur changement.

La syntaxe est plus longue, mais c'est facilement géré avec un IDE via des snippets et la clarté et la standardisation apportent plus de valeur que la concision.
De plus on aura probablement besoin de seulement 1 ou 2 loggers par classe, le code réèl ressemblerait plutot a cela :

self::$cmdLogger = log::getLogger('cmd');
// ...
self::$cmdLogger->info('Mon message');

On peut utiliser directement les fonctions rajoutées par ta PR (debug, notice, info...) ce qui permet aussi de raccourcir le code en supprimant le premier paramètre.

[Mips2648]

L'intérêt de mon code c'est de pouvoir utiliser des class externes qui demandent une compatibilité avec cette interface (je l'ai fait avec succès dans plusieurs plugins)
Implémenter une interface standard ne veut pas dire qu'on ne peut pas supporter/implémenter d'autres méthodes en plus (la méthode historique du core ici)

la question n'était pas de savoir si une compatibilité / implémentation standard est intéressante (ca c'était l'objet de ma PR) mais de savoir en quoi supprimer l'implémentation historique apporte un avantage? que va-t-on gagner?
Celle-ci ne gêne en rien et peut rester indéfiniment d'après moi.
Migrer va demander énormément de temps et d'énergie (certaines plugins ne seront JAMAIS mis à jour et on n'a aucun contrôle la-dessus) tout ca pour gagner quoi? A quelle stratégie cela permet de répondre?
Je n'y vois aucun gain, au contraire.

Même ne faire que flag ceci en deprecated avec un trigger_error va avoir des conséquences désastreuses en nombres de questions sur community, et je me répète, quasi jamais il ne sera possible de supprimer cette implémentation.

Je confirme que je suis toujours contre.

[kwizer15]

Merci pour ces éclaicissements, je comprend mieux ce que tu souhaitais faire et ton opposition à déprecier cette methode. Rien n'empeche d'avoir ces 2 méthodes en paralléle.

Je vais donc fermer cette PR.

Pour le besoin que tu avais, il me semble qu'un pattern adapter aurait été plus approprié. Cela aurait permis, en premier lieu, d'éviter cette incompréhension, d'avoir une classe dédié à ce besoin spécifique de brancher du psr-3 a d'autre classes, et d'éviter la pollution de la classe log historique avec du code spécifique.
Je peux éventuellement proposer une PR dans ce sens si tu le souhaites.

[kwizer15]

Pour info, j'ai créé une nouvelle PR sur mon fork (https://github.com/kwizer15/core/pull/2/files) qui propose l'implémentation du pattern adapter dont je parlais. Cette approche permet d'avoir une meilleure séparation des responsabilités tout en gardant intacte la classe historique.