On Fri, 17 Aug 2001 09:03, Morgan Delagrange wrote:
> Hmm, I don't see the big deal.  A String is an Object, and every Object has
> a toString() method.  It's common practice to accept Objects can call
> toString() on them.

then whats the point of passing in an object? If its not a big deal then it 
should be an easy change ;)

> I would not expect this method to be used very often, but it's important
> for legacy products that don't want to change their API.  Otherwise you
> have to remove all those setDebug() methods from the code, which means all
> the dependant projects have to change _their_ code, and it's a big, big
> mess. It would be much better to handle the transition between logging
> methods transparently.  That way, those legacy projects can enable
> debugging through their old methods _or_ externally.

So have the default implementation have a similar method and call that. I am 
not sure why it needs to be part of the interface.

> > Could you outline?
>
> I have no idea if all loggers will support this well or at all.

Its one line if they don't - in many ways it is easier if they don't ;) See 
Syslog example posted before.

> > > Also it's possible that loggers won't support it at all.  The
> > > only current requirement of the Logging component is a String name for
> > > a logging category; this is not guaranteed to be a parseable hierarchy.
> >
> > true but all logging toolkits I know of do do it to some degree or
>
> another.
>
> What about the toolkits you don't know about?  ;)

I have looked at all the ones I could find. And as I said - if they don't 
support it then it is even easier to integrate ;)

-- 
Cheers,

Pete

*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof."                   *
*              - John Kenneth Galbraith               *
*-----------------------------------------------------*

Reply via email to