I like the sound of this approach as well. > Paul, > >> I'd normally advocate an interface approach here, I think >> that is a major >> structural change, and dangerous unless we specifically >> designed to do it as >> part of a major release, and not part of a lot of other >> general changes that >> are going on now. >> >> I'd advocate leaving the LoggingEvent class as is, bar adding >> a protected >> no-arg constructor, and defining protected final setter >> methods that modify >> the internal data elements. This gives different classes >> that may want to >> produce a LoggingEvent instance the ability to instantiate their own >> LoggingEvent sub-class, and utilise the protected final >> setter methods, but >> allow every other class that is purely a consumer to view the >> LoggingEvent >> as it currently is with no changes (a immutable object, >> actually since it >> has setters, probably a 'read-almost-always' object). I >> _think_ that is as >> close to binary and backward compatabile as you would get..? > > Interesting approach. We should consider it. > > -Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
