[
https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13832616#comment-13832616
]
Ben edited comment on LOG4NET-409 at 11/26/13 2:28 PM:
-------------------------------------------------------
I can see that no one is liking this idea, but I do still think it is important.
{quote}
... on the other hand we would gain the benefit of type safe parameters inside
the log4net code.
{quote}
What about my code Michael? As a user of log4net, why can't I have type safety
too, or do you not care about me? When I explained my real-world example where
I lost a customer because I didn't get a critical Error log message, is this
not important to you? Is this not a valid reason? I don't want to loose
customers - they are the most important thing in my business.
To be quite honest I think that any method that accepts an object type as a
parameter is dangerous. Because anything can be passed to it - any crap - and
there is no error, no exception thrown, nothing to suggest anything is wrong.
The Console.WriteLine method is also dangerous. Any method that accepts a
parameter of type object has a code smell and rings alarm bells. One of the
biggest benefits of Generics was to fix exactly this problem.
Benefits of Generics
http://msdn.microsoft.com/en-us/library/vstudio/b5bx6xee.aspx
{quote}
Generics provide the solution to a limitation in earlier versions of the common
language runtime and the C# language in which generalization is accomplished by
casting types to and from the universal base type Object. By creating a generic
class, you can create a collection that is type-safe at compile-time.
{quote}
The *only* time that object should be used as a type is when you are dealing
with earlier versions of the CLR *and* you are dealing with objects that are so
diverse that you can't provide the user with an interface. To use, object just
because it has a useful ToString() method is just lazy.
To be quite blunt guys, your log4net logger methods smell bad.
Sure, perhaps most people don't care, and perhaps most people will just send
strings and exceptions to their loggers. Maybe I am using log4net in a very
eccentric way and so maybe I am a one-off special case that you don't need to
worry about. These are good arguments for not implementing this and just
leaving the API as it is. But please don't say that my reasoning is bad -
because it is not. There would be a very good reason for introducing Generics
to the logger API - because it would provide your users with type-safety in
_their_ code (which may vary a lot from user to user - flexibility is an
important log4net feature right?).
I can accept that I am a one-off special case, so no worries, I have already
created my work-around and implemented something similar to Dominik's wrapper
suggestion (thanks by the way). As I said already, it works as a separate
add-on assembly and so the code is separate from the main log4net dll. As an
add-on, I still get to use the normal loggers which is great, but now I can
also use special generic loggers when I want type-safety. The API for the
generic logger and the normal logger is not mixed up and so it is kept separate
and clean from each other. It might be worth at least having a look at?
Perhaps there might be other users out there who might also like to use this
code?
was (Author: benixix):
I can see that no one is liking this idea, but I do still think it is important.
{quote}
... on the other hand we would gain the benefit of type safe parameters inside
the log4net code.
{quote}
What about my code Michael? As a user of log4net, why can't I have type safety
too, or do you not care about me? When I explained my real-world example where
I lost a customer because I didn't get a critical Error log message, is this
not important to you? Is this not a valid reason? I don't want to loose
customers - they are the most important thing in my business.
To be quite honest I think that any method that accepts an object type as a
parameter is dangerous. Because anything can be passed to it - any crap - and
there is no error, no exception thrown, nothing to suggest anything is wrong.
The Console.WriteLine method is also dangerous. Any method that accepts a
parameter of type object has a code smell and rings alarm bells. One of the
biggest benefits of Generics was to fix exactly this problem.
Benefits of Generics
http://msdn.microsoft.com/en-us/library/vstudio/b5bx6xee.aspx
{quote}
Generics provide the solution to a limitation in earlier versions of the common
language runtime and the C# language in which generalization is accomplished by
casting types to and from the universal base type Object. By creating a generic
class, you can create a collection that is type-safe at compile-time.
{quote}
The *only* time that object should be used as a type is when you are dealing
with earlier versions of the CLR *and* you are dealing with objects that are so
diverse that you can't provide the user with an interface. To use, object just
because it has a useful ToString() method is just lazy.
To be quite blunt guys, your log4net logger methods smell bad.
Sure, perhaps most people don't care, and perhaps most people will just send
strings and exceptions to their loggers. Maybe I am using log4net in a very
eccentric way and so maybe I am a one-off special case that you don't need to
worry about. These are good arguments for not implementing this and just
leaving the API as it is. But please don't say that my reasoning is bad -
because it is not. There would be a very good reason for introducing Generics
to the logger API - because it would provide your users with type-safety in
_their_ code (which may be in very different ways - flexibility is an important
log4net feature right?).
I can accept that I am a one-off special case, so no worries, I have already
created my work-around and implemented something similar to Dominik's wrapper
suggestion (thanks by the way). As I said already, it works as a separate
add-on assembly and so the code is separate from the main log4net dll. As an
add-on, I still get to use the normal loggers which is great, but now I can
also use special generic loggers when I want type-safety. The API for the
generic logger and the normal logger is not mixed up and so it is kept separate
and clean from each other. It might be worth at least having a look at?
Perhaps there might be other users out there who might also like to use this
code?
> 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)
