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.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org