On Monday, 27 October 2014 at 20:49:35 UTC, Dicebot wrote:
On Monday, 27 October 2014 at 20:42:10 UTC, Martin Nowak wrote:
Say I want to add tracing/logging to
[`parseJson`](http://dlang.org/library/std/json/parseJSON.html)
or
[`findRoot`](http://dlang.org/phobos/std_numeric.html#.findRoot)
This is exactly what is wrong :) Using std.logger inside Phobos
itself is a big no. Actually even finding yourself in position
where you may want to do it indicates some Phobos design issue.
Yes and No. His Logger can came from the user aka. outside of
phobos. That might just be valid. But the problem with the design
is that he needs to accept every possible Logger. And that either
means template of abstract class Logger.
The problem with a template is:
``` library code that is given in binary form
auto fun(Logger l) {
return parseJson(getData(), l);
}
```
their is no choice but to pass a class. Meaning you have to wrap
the struct Logger with a class proxy. And this will properly
develop into a common theme.
Allowing struct has one design problem IMO:
Either we force to callee to accept Logger as template or
we force the caller to wrap his Logger struct with Logger proxy
classes.
This is because an abstract class is the lowest common
denominator in this case.
Anyway, I'm pretty sure that Martin and I will never see eye to
eye in this discussion. IMO disabling a single Logger through its
LogLevel at compile (plus all the extra litter and possible
needed wrapping) is no better than creating NullLogger. He thinks
the opposite.
The problem for me now is, if I add a struct UFCS overload Martin
will be happy but somebody else will stream WAT "The struct stuff
must go"
So please everybody reading this, please give a comment about
this.
