[slf4j-dev] [Bug 163] Copy & paste of LoggerFactory.getLogger
bugzilla-daemon at pixie.qos.ch
bugzilla-daemon at pixie.qos.ch
Tue Dec 15 15:23:13 CET 2009
http://bugzilla.slf4j.org/show_bug.cgi?id=163
--- Comment #12 from Thorsten <thorsten.Moeller at unibas.ch> 2009-12-15 15:23:12 ---
(In reply to comment #11)
> > add a short documentation
>
> Yes, that would be great! It's a good solution, but
> also not perfect. What I don't like about it is:
> I think libraries shouldn't rely on IDE features.
Well, my proposal does not make SLF4J rely nor depend on features of a
particular IDE. It is just a proposal showing an example of how one can take
advantage of functionality provided by modern tools. In other words, not every
problem that developer might face when using some library can or should be
tried to solve by making source code changes if there is tooling support that
can nicely solve a particular problem. To say it in yet even other words, the
problem that you face is not a matter of functionality missing in SLF4J but a
matter of "how" one works (and maybe it is necessary to rethink the latter).
> Ideally, the library should provide a solution for the
> libraries problems, not the IDE. So, an Eclipse template
> also is a workaround (not the worst one however).
As I tried to convey, it is not a workaround but an example to make people
aware and to guide them towards a direction on what they should do to prevent
falling into error-prone programming patterns.
> > probably leaky extensions
>
> Sorry, what do you mean with leaky extension?
> Leaky as in leaks memory? It doesn't leak memory.
> The 500/230 bytes are purely jar file size, not heap memory.
You are right, was not the best wording as it can be easily misunderstood. I
should have probably used "tricky".
--
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the slf4j-dev
mailing list