After reading Geir's excellent debate on the subject, I would actually like to jump on the String bandwagon. I think that it is clear what you are trying to do if you are logging strings (and possibly Throwables).
Scott > -----Original Message----- > From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 30, 2002 8:28 AM > To: Jakarta Commons Developers List > Subject: Re: [Logging] [VOTE] Commons Logging 1.0 Release > > > On 1/30/02 11:07 AM, "Craig R. McClanahan" > <[EMAIL PROTECTED]> wrote: > > > > > > > On Wed, 30 Jan 2002, Geir Magnusson Jr. wrote: > > > >> Date: Wed, 30 Jan 2002 07:00:22 -0500 > >> From: Geir Magnusson Jr. <[EMAIL PROTECTED]> > >> Reply-To: Jakarta Commons Developers List > >> <[EMAIL PROTECTED]> > >> To: Jakarta Commons Developers List > <[EMAIL PROTECTED]> > >> Subject: Re: [Logging] [VOTE] Commons Logging 1.0 Release > >> > >> On 1/29/02 3:56 PM, "Waldhoff, Rodney" > <[EMAIL PROTECTED]> > >> wrote: > >> > >>>> you may want to consider making the parameters > >>>> Strings not objects. They were made strings so that > >>>> you could render objects with Log4j. No other logging > toolkit does > >>>> this. Thus if this is allowed/used you are directly binding to > >>>> Log4j anyway - why not use Log4j directly in that case? > >>> > >>> What's it hurt to leave Objects in there? > String.valueOf(object) is > >>> easy enough to do, and it supports the richer > functionality provided > >>> by log4j. Why go out of our way to restrict functionality that's > >>> otherwise trivial to support? > >> > >> Is there other 'richer' functionality in other logging > systems that > >> you may want to support also? > >> > > > > I might want to write my own "in between" wrappers (application > > specific) that are object-aware, and that then pass the > message on to > > the underlying logging system. > > Yep - sure - that's reasonable - but that's an issue above > the logging Fa�ade, right? (Well, can be..) > > > Turn the question around, as well. What is the technical > benefit in > > changing the argument to String? > > I don�t see it as 'either-or', but 'both'. The advantage of > Strings is that the contract is clear. Passing Object is a > little suspect - I have no idea what you want out of me when > I do that. (me == inteface user...) > > And for 'both', if you then offer a overload that takes > Object, then I can choose. > > >> I see peters point, although I am suspicious of his motivation :) > >> > > > > Can we please cut the personalities crap and talk about technical > > things for once? Even with smiley faces, this is getting > pretty old. > > > > It's not a personality thing. My suspicion wasn't based on > any judgment or assessment of his *personality* but his > *motivation*. Hence, I used the word 'motivation'. > Technical decisions are also driven by motivation.. > > (and so are political decisions, and business decisions, and...) > > And I like Peter. Don't always agree, but like him. > > Here's a non-smiley face for you : > > :/ > > > -- > Geir Magnusson Jr. > [EMAIL PROTECTED] > System and Software Consulting > "They that can give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." - > Benjamin Franklin > > > > -- > To unsubscribe, e-mail: > <mailto:commons-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
