On 1/29/02 4:03 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> > > On Tue, 29 Jan 2002, Waldhoff, Rodney wrote: > >> Date: Tue, 29 Jan 2002 14:56:39 -0600 >> From: "Waldhoff, Rodney" <[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 >> >>> 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? > > Changing Object to String would in fact represent a loss of functionality > if the underlying logging implementation you are using knows how to deal > with Objects in interesting ways (for example, it might use reflection to > dump out all the bean properties). > Sure, but that isn't in the contract implicit in the interface, is it? There is no reason to believe that anything passed in is a bean, for starters. Also, why should I trust the underlying impl to not do wacky things to the objects I pass in? Like invoke methods arbitrarily? One solution might be to offer overloaded methods, and allow an impl to throw some kind of NotImplementedException for the methods that take Objects, so I have both safety as well as freedom. (You generally have to give up one for the other...) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting "He who throws mud only loses ground." - Fat Albert -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
