Since the change to PSR-3 the Flow framework loggers were in a part floating space on how to correctly use them. There were intermediary b/c interfaces
PsrSecurityLoggerInterface which were marked deprecated and the default configuration when injecting the
Psr\Log\LoggerInterface was the systemLogger, though that was totally undocumented, let alone how to get hold of any of the other loggers.
With the “virtual objects” feature we introduced, we have a way to configure multiple instances of a single interface or class, which seemed like a perfect fit for the loggers use case. But @daniellienert rightfully brought up a concern, that virtual objects lack autocomplete support and typing the additional string name is worse than only typing the interface you need injected.
So we’re at the point where we should make a decision about which way to follow and document as the defacto standard of creating and injecting different loggers for the longer run:
- use virtual objects
/** * @Flow\Inject(name="Neos.Flow:SystemLogger") * @var \Psr\Log\LoggerInterface */
- use specific interface for each logger
/** * @Flow\Inject * @var SystemLoggerInterface */
IMO the main PRO for the interface is the autocompletion in the IDE, the CON is that the interfaces are abused as markers and not a promise for the methods available (only via inheritance extends
See https://github.com/neos/flow-development-collection/pull/2134#discussion_r491677486 for the initial discussion
- virtual objects
- (marker) interfaces