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 *
*-----------------------------------------------------*