I don't think it's theoretically possible to have the same trait "instance"
recognize which superclass that it was mixed in to is doing the logging.
Because if A mixes in T, and B extends A and also mixes in T, T is not
really mixed in twice. For the same reason using a type parameter would not
help because any given class can only have one type "value."
The closest thing I can think of is using the stack trace to find the method
calling the logging method, and figuring out which trait it comes from. In
other words, not a solution.
If it's important, you may want the logging method to take an implicit
parameter, say of type
case class LoggerName(name: String)
Then your trait can provide a default implicit, but I'm guessing if a
subclass has it's own (say private) implicit val, it would be used.
To determine if this is true, try:
case class N(s: String)
trait T {
implicit val x = N("t")
def m(implicit p: N) = println(p)
}
class A extends T {
private implicit val y = N("a")
m
}
class B extends A {
private implicit val z = N("b")
m
}
new T {}
new A
new B
2010/2/15 Jeppe Nejsum Madsen <[email protected]>
> On Mon, Feb 15, 2010 at 9:57 PM, Indrajit Raychaudhuri
> <[email protected]> wrote:
>
> >>
> http://github.com/dpp/liftweb/blob/add01980aa81875617f38260d710e0558c7ae1b1/framework/lift-base/lift-common/src/main/scala/net/liftweb/common/Logging.scala
> >>
> >> One issue remains, which I don't know how to handle (if possible at
> >> all): The current mixins use the dynamic type of an instance to
> >> determine the logger name. This may not always be the preferred way.
> >> E.g:
> >>
> >> trait PaymentSystem extends Logger
> >> trait FullfillmentSystem extends Logger
> >>
> >> object MyStore extends PaymentSystem with FullfillmentSystem with Logger
> >>
> >> Now everything in the subsystems will be logged with the MyStore
> >> logger which is not how I would like to see it. The only solution I've
> >> found so far is to not use the mixins and create private loggers in
> >> the subsystem, where the static type is known. E.g. val logger =
> >> Logger(classOf[PaymentSystem])
> >>
> >> But this kind of restricts the usage of the mixins. Any thoughts on
> >> this issue is appreciated....
> >
> > The restriction might be worthwhile in this case for the sake of
> > predictability. Having class/object specific logger is to be able to
> filter
> > in/out the logs (via configuration) at deployment time. It should not be
> too
> > sensitive to minor rearrangement of mixins in the code.
> >
> > Would it be overcomplicated to make the Logger trait typed?
>
> Not sure I follow? Logger is already a trait...Or did you mean something
> else?
>
> Having thought a little more about this, it seems like both solutions
> (mixin and private loggers) has their uses:
>
> Mixins as convenience for application services that should not be
> subclassed and private loggers for reusable components .
>
> /Jeppe
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<liftweb%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
