[
https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831528#comment-13831528
]
Dominik Psenner commented on LOG4NET-409:
-----------------------------------------
{quote}To be quite honest I am feeling quite a bit of hostility in your comment
Dominik{quote}
Apologies, it wasn't meant as an offense. I've tried to outline how log4net
does what you want from it to pin down your usecases that log4net currently is
not able to fulfill.
{quote} don't think that it would pollute the API at all.{quote}
Currently there are more than 10 overloads to log a Info event and adding
generics would at least double that number. Now take that number and multiply
it by 6 (trace, debug, info, warn, error, fatal) and this story starts sounding
like a large amount of overloads.
{quote} The logic would be the same.{quote}
With "logic" I meant the logic implemented on the application level which uses
log4net. Mileage may vary, but the purpose of different logger instances is to
logically group together sensible event sources. Pumping in generics at the
construction of logger instances could make sense, but not at the logging
calls. Just alike nobody cares about the type safety of Console.WriteLine().
{quote}Look - At the end of the day, log4net is your project and you must run
it the way you see fit, so if you don't like this idea then that is fine.{quote}
To me there are several good reasons to not implement this issue. But finding
out that the world is not a pizza also needed more than just one brain. :-)
> Generics added to the Logger
> ----------------------------
>
> Key: LOG4NET-409
> URL: https://issues.apache.org/jira/browse/LOG4NET-409
> Project: Log4net
> Issue Type: Wish
> Components: Core
> Affects Versions: 1.3.0
> Reporter: Ben
> Labels: features
>
> Maybe this has been suggested before - if so sorry (I did do a search for it).
> I am fairly new to log4net and when I am using it, I was surprised to see
> that the log methods take an object as a parameter. Of course this made
> sense after I found out that Object Renderers can be made to parse any type
> of object. I did wonder why Generics was not used.
> If I have an Object Renderer that knows how to log Orange objects then I
> don't want to accidentally pass it an Apple object (or any other type of
> object).
> So using Generics I would set up my logger as follows:
> private ILog<Orange> myOrangeLogger =
> LogManager.GetLogger<Orange>("OrangeLogger");
> I have just made a special type of logger that can log oranges. Instead of
> accepting parameters of type object it accepts only strings and Oranges.
> Behind the scenes the method
> LogManager.GetLogger<T>(string name)
> would return a logger of type ILog<T>.
> The ILog<T> interface would have methods on it like:
> ILog<T>.Warn(string message);
> ILog<T>.Warn(T message);
> ILog<T>.Warn(string message, Exception ex);
> ILog<T>.Warn(T message, Exception ex);
> but would NOT have the method:
> ILog<T>.Warn(object message);
> So now if I tried to pass it an Apple object I would get a compile error
> rather than the default behaviour for a logger which has been given an object
> that has no special renderer (in fact I probably wouldn't even realise until
> I went to look at the log files right?). This would be much better and would
> help to save me from embarrassing myself in front of my customers.
> This could be added in addition to the standard loggers which would still be
> returned in the normal way using:
> LogManager.GetLogger(string name);
> If this has not already been suggested then I hope you like this idea.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
