Declaring logger outside the class vs. inside

[djkeh]

Declaring logger outside the class vs. inside

[djkeh]

Thank you for the opinions. The common idea on the ground seems that the logger should be static. We need to think about this.

1. Like I said, it may not necessarily be static. What is the traditional purpose of being static? What I know is that we need only one logger, and we don't want to create it twice. And it is ALREADY one, it is created via object, so it is singleton. It will never be created twice in the name of kotlin.
2. The performance between the approach to get the only instance from singleton and from the static is controversial nowadays, more and more people believe singleton logger is fast enough compared to the static logger. Some people even believe the instance is now faster than the static object. The logger instance in the heap memory also has some benefits that the static logger doesn't.
3. The second important view is that, it still works anyway if you put it in the class property. It can be considered as another traditional pattern as well to put logger in the source code. So why is it considered bad and should be avoided? I believe we need clearer reason not to put it inside the class other than "to make it static".

ps. @DanielGolan-mc You are right, I don't want to put it in the companion object, either. It sucks.

[oshai]

We wanted to have one instance of logger per class / file (and not per instance of the class). In order to do that there are few options:

• outside of the class.
• in an object / companion object.

Initially both options were available, but in order to have one standard way we decided to recommend only the outside of the class style. It makes some sense to have a logger per file in most cases.

So where to put the declaration is mostly a style thing, and the style we chose is to have it outside of the class.
Other options are still possible to some extent.
Hope that clarifies things.

[oshai]

What if we allow a logger per instance of the class as the standard style?

This is inefficient in terms of memory usage (additional pointer for each instance) so not recommended. Also in java it's usually static.
You can still do it, but it's not going to be the recommendation.

[github-actions]

Thank you for reporting an issue. See the wiki for documentation and slack for questions.

[recursive-rat4]

Kotlin doesn't support static members yet, for details you can see KEEP-348.

[DanielGolan-mc]

class MyClass {
    companion object {
        internal val logger = KotlinLogging.logger { }
    }
}

This is a semi-static variation of what you want. Using private here won't allow the class to use the logger, and using internal allows the entire project to use this logger. So for now, declare the logger outside of the class. Shouldn't turn your class's file icon into the kotlin symbol instead of a class icon if you care about that.

In my own library, I just turned the loggers into a part of some classes' lifecycles.

[djkeh]

Thanks @oshai , I think that clarifies things enough.
I think the current style is good enough for the standard of kotlin-logging.
I'd just like to ask an additional question before closing this issue.

What if we allow a logger per instance of the class as the standard style?
There are some benefits that comes out of my head:

1. We can stick to the java convention, which states that a file contains a class. This idea is not mandatory on the kotlin side though.
2. We can have a bit smoother IDE support in the situations like duplicating source codes.
3. There would be no confusion between loggers in the files that shares the same package names.

com
└── me
    └── example
        └── service
            ├── MyExample1.kt
            └── MyExample2.kt

In this example above, the full names of the logger fields would be: com.me.example.service.logger,
and these loggers serves different classes, in this case MyExample1 and MyExample2.

[djkeh]

Thanks for the explanation. I close this issue now.