On Fri, Dec 5, 2014 at 11:41 AM, Gary Gregory <[email protected]> wrote:
> On Fri, Dec 5, 2014 at 11:14 AM, Ralph Goers <[email protected]> > wrote: > >> I think I would find this confusing. There are already a set of >> logger.trace, logger.debug, etc methods that take arguments. Having a set >> of trace, debug, etc methods that don’t have args but accept a log method >> would mean that people might code logger.trace(“This {} and that{}”, this, >> that); when they meant to code logger.trace().log(“This {} and that {}”, >> this, that);. Furthermore, they might have coded >> >> logger.trace().log(“This {}, that {}, the other {}”, this, that, other); >> >> and then later change it to >> >> logger.trace().log(“This {}, that {}, the other {}, whatever {}”, this, >> that, other, whatever); >> >> Which essentially means that the log method has to support all the >> variations that are already in the API. >> >> I do see the advantage that each of the trace(), debug(), etc methods can >> return an interface that has all the log methods, but I don’t like the idea >> of having both API formats. >> > Maybe something like this then: http://pastebin.com/vQdmWUBD Maybe Logger and LevelLogger could have a common super interface. Gary > > OK, so back to the original issue while I keep experimenting. Would you be > OK with adding to the Logger API: > > void info(Marker marker, String message, Object arg0); > void info(Marker marker, String message, Object arg0, Object arg1); > void info(Marker marker, String message, Object arg0, Object arg1, Object > arg2); > > and so on? > > Gary > > >> Ralph >> >> >> On Dec 5, 2014, at 8:08 AM, Gary Gregory <[email protected]> wrote: >> >> Hi All: >> >> I've thinking about adding 1, 2 and 3 arg variants to the Object... >> methods in Logger to avoid paying the cost of creating Object arrays. This >> is especially important when no logging takes place and I have a call like >> >> logger.trace("this {} and that {}", this, that); >> logger.debug("this {} and that {}", this, that); >> >> But the idea of adding 3 extra method times the number of log levels is >> not appealing. >> >> So that go me to consider this call side pattern: >> >> logger.trace.log.("this {} and that {}", this, that); >> logger.debug.log("this {} and that {}", this, that); >> >> where trace could be "trace()" a method, or "trace" a public ivar. >> >> Obviously, this would eliminate the need to duplicate method patterns for >> each level when we want new APIs. >> >> Thoughts? >> >> Gary >> >> >> -- >> E-Mail: [email protected] | [email protected] >> Java Persistence with Hibernate, Second Edition >> <http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> >> >> > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
