Add a way to create log without side effects

[FunFunFine]

Currently LogOf creates desired Log instances with a side-effect. But there is a simple way to avoid that and get plain Log[F], not F[Log[F]]. This is possible because of the fact that both SLF4J and Logback cache their loggers (which LogOf relies on).
This means that it is totally fine to call loggerFactory.getLogger(source) on each log message, because the overhead is simply a hash table call and a couple of if-s.

The names and the details in this PR are subject to change, let's discuss it all.

[t3hnar]

this is still an effectful unpure code, hence - NO from my side. however you can already use logOf(…).toTry.get in your code base, which will clearly express to readers unsafeness, and this is easy to use

[FunFunFine]

Why is that an effectual code?

[FunFunFine]

If you worry about getting the factory in safe manner then check out test file in this PR. It shows that we still should get ILoggerFactory by delaying slf4j stuff.

[t3hnar]

because any manipulations with factory are not safe, and in runtime it really references mutable shared state and changes it

[FunFunFine]

Well, I see what you mean. It easily can be solved by putting function here (it should be done anyway because of Logback) like so

def cached[F[_] : Sync](source: String, factory: String => F[Logger]): Log[F] = ???

or by putting factory inside of Ref. I guess it would be pure code then, right?

[FunFunFine]

Also I see that every manipulation with factory is delayed here, isn't it enough to be pure?

[t3hnar]

right!

however such changes would enforce your Log implementation to call factory.getLogger as part of log.info/debug/etc - adds some runtime overhead

[FunFunFine]

Such runtime overhead is so little we can ignore it. If you dive in (not so deep) to the implementation, you can see that:

private Map<String, Logger> loggerCache;
//...
public final Logger getLogger(final String name) {

        if (name == null) {
            throw new IllegalArgumentException("name argument cannot be null");
        }

        // if we are asking for the root logger, then let us return it without
        // wasting time
        if (Logger.ROOT_LOGGER_NAME.equalsIgnoreCase(name)) {
            return root;
        }

        int i = 0;
        Logger logger = root;

        // check if the desired logger exists, if it does, return it
        // without further ado.
        Logger childLogger = (Logger) loggerCache.get(name);
    //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this line   
        // if we have the child, then let us return it without wasting time
        if (childLogger != null) {
            return childLogger;
        }

        // if the desired logger does not exist, them create all the loggers
        // in between as well (if they don't already exist)

//....

}

[FunFunFine]

You know when you create instances of IO and flatMap classes for every operation you make this overhead seems totally fine.

[t3hnar]

sure it might be totally fine, it depends on actual implementation :)

def cached[F[_] : Sync](source: String, factory: String => F[Logger]): Log[F]

signaturewise & typewise - is ok

[FunFunFine]

One important thing to discuss is how to integrate it in existing code.
If LogOf had two type-parameters, then it would be simpler: just make a LogOf[Id, F] returning method. But it doesn't hence we need to create another one.
Should we even force the migration to this new version, if it is any good?

[t3hnar]

trait MyClass[A[_], B[_], C[_]] {
  def a: A[…]
  def b: B[…]
  def c: C[…]
}

gives the most flexibility, however usually you just do not need that, basically single F[_] is the most common case without over complications. Different might not even give you composability :)

hence I'd recommend to NOT overcomplicate, imho .toTry.get will be simpler :)

[FunFunFine]

hence I'd recommend to NOT overcomplicate, imho .toTry.get will be simpler :)

I do not want to make my code impure. .toTry.get won't work for me unfortunately.

[FunFunFine]

```scala
trait MyClass[A[_], B[_], C[_]] {
  def a: A[…]
  def b: B[…]
  def c: C[…]
}

gives the most flexibility, however usually you just do not need that, basically single F[_] is the most common case without over complications.

Regarding multiple type parameters: I was talking about such approach:

trait LogOf[I[_], F[_]] {
  def apply(source: String): I[Log[F]]
}

where I denotes your initialisation effect and F is your main effect where your app runs.
For example, I =:= IO & F =:= ReaderT[IO, MyRequestContext, *], when your app runs in some contextual environment (e.g. context extracted from HTTP request).