Our DI is able to inject a logger implementation to any server and app
class if they want one. However, sometimes DI isn't applicable or hard
to add. In those cases we typically fell back to the *service locator*
pattern where we acquired a logger from the server via a global
variable.
There were some issues with that
* `\OC` is a private class, apps are not supposed to use it
* `\OC::$server` is a global variable, a well known anti-pattern
* `\OC::$server->get(...)` uses the service locator anti-pattern
* `\OC::$server->get(...)` may throw
* `\OC::$server->get(LoggerInterface::class)` is not scoped to an app
With this patch I'm proposing a new helper function ``\OCP\Log\logger``
that can be used to acquire a logger more easily. This function is meant
to be public API and therefore apps may use it and there is an optional
parameter to specifiy the app ID.
The function hides all the ugly details about the global variable and
the potentially thrown exceptions from the user. Therefore it's
guaranteed that you always get a logger instance. In the worst case you
get a noop, though those occasions should be rare.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
To continue this formatting madness, here's a tiny patch that adds
unified formatting for control structures like if and loops as well as
classes, their methods and anonymous functions. This basically forces
the constructs to start on the same line. This is not exactly what PSR2
wants, but I think we can have a few exceptions with "our" style. The
starting of braces on the same line is pracrically standard for our
code.
This also removes and empty lines from method/function bodies at the
beginning and end.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
