Ceki,
I think you are right: There seems to be no need for an abstract Logger (trait or abstract class) and a default implementation. Better have a single concrete Logger class wrapping a SLF4JLogger instance.
How shall we proceed? Wait some time and do the change then? Change it immediately?
Heiko
On 1 November 2010 22:28, Ceki Gülcü
<ceki@qos.ch> wrote:
Hello Heiko,
Looking at logger.scala, I was wondering why the Logger trait was a trait and not a class. I understand that as a trait any class can mixin Logger and methods such as debug(), info() would be available in that class. However, there is already a trait caller Logging which allows the mixing class to write logger.debug("...").
It seems to me that the Logging trait is sufficient in most cases. I would like to propose to make Logger a class instead of a Trait and to get rid of DefaultLogger. This would make the code a little simpler without loss of "desired" flexibility. I don't think we should allow classes to write just debug("...") or should we?
WDYT?
--
Ceki
_______________________________________________
slf4j-dev mailing list
slf4j-dev@qos.ch
http://qos.ch/mailman/listinfo/slf4j-dev
--
Heiko Seeberger
Company:
weiglewilczek.comBlog:
heikoseeberger.name
Follow me:
twitter.com/hseebergerOSGi on Scala:
scalamodules.orgLift, the simply functional web framework:
liftweb.net
Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors:
akkasource.org