[Feature Request] Create logger builders from existing loggers about spdlog-rs HOT 6 CLOSED

At the very least we should simplify the procedure to create new loggers based on the default logger providing a different name. It's a very common practice for library authors.

from spdlog-rs.

Interesting suggestion, which involves some details to consider.

First, there is actually a simpler way to do this than your first example.

let mut new_logger = spdlog::default_logger().deref().clone();
new_logger.set_name(Some("new name"));

(Logger::set_name here does not currently exist, I just forgot it XD, and implement it is easy)

Based on this, we need to reconsider the need for a shorthand method. I don't completely reject your proposal, but we need to figure out the following questions:

• In the current implementation, in order to implement periodic flushing, the receiver of set_flush_period is &Arc<Self> (code).

  LoggerBuilder returns Logger instead of Arc<Logger>, so it's not possible for Logger::new_from_logger to exactly replicate all the arguments of a logger (periodic flushing will not work on the new logger, if the old logger set it).

  Neither can my example above, which would cause a panic at runtime if a flush period is set (code). So along with set_name, a try_clone may also need to be implemented.

• So it should be possible to implement a

  Logger::clone_with(self: &Arc<Self>, modifier: impl FnOnce(&mut Logger)) -> Arc<Logger>

  , and it will be used in this way:

  let new_logger = spdlog::default_logger().clone_with(|new| new.set_name("new logger"));

  Compared to the above code, it is just one less line. However, since it serves only Arc<Logger>, it should be able to replicate all arguments (although users cannot modify the flush period in the closure).

• Further, I think that if we can find a way to implement the receiver of set_flush_period as &Logger instead of the current &Arc<Logger>, and it doesn't cost much (e.g. performance, interoperability, etc.), then my first example is short enough and should be able to replicate all the arguments, so we don't need a clone_with shorthand, which is probably the best.

from spdlog-rs.

from spdlog-rs.

clone_with_name should not be too different from clone_with, its function signature also requires the same receiver &Arc<Logger> and the same return type Arc<Logger>. I prefer clone_with because it provides more interoperability, so that in addition to downstream library code, downstream binary code will also benefit, as downstream binary code is particularly interested in properties such as sinks.

from spdlog-rs.

I suggest we add both of clone_with and clone_with_name, and make clone_with_name a convenient wrapper around clone_with.

from spdlog-rs.

I suggest we add both of clone_with and clone_with_name, and make clone_with_name a convenient wrapper around clone_with.

Agree with that, I will open a PR later :)

from spdlog-rs.