Skip to content

level may be anything #22

@derrabus

Description

@derrabus

With #15, a now array shape log_record_array was introduced which documents the level as string. However, accoring to the specification, a logger implementation may accept custom log levels on the log() method, which is why it documents the log level as mixed.

https://www.php-fig.org/psr/psr-3/#11-basics

A ninth method, log, accepts a log level as the first argument. Calling this method with one of the log level constants MUST have the same result as calling the level-specific method. Calling this method with a level not defined by this specification MUST throw a Psr\Log\InvalidArgumentException if the implementation does not know about the level. Users SHOULD NOT use a custom level without knowing for sure the current implementation supports it.

The important part here is, "if the implementation does not know about the level". The purpose of the TestLogger is that applications can test the interaction of their logic with loggers without actually writing logs. This means that testing the interaction with a logger implementation that accepts, let's say, enum log levels is a valid use-case and TestLogger should function as a drop-in replacement for such implementations as well. Also note that TestLogger currently does not check the validity of the value passed as $level: the value is stored as-is in the $records array structure.

Note that I'm personally not affected by this issue. I just noticed it while reviewing other typing issues of #15 and felt like this particular change should've been discussed at least.

Still, my proposal here is to widen the level key to mixed as specified by PSR-3.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions