On Mon, Aug 4, 2008 at 10:13 AM, Ceki Gulcu <[EMAIL PROTECTED]> wrote: > > OK, you've got me convinced. Consider the fix done.
Nice. ;) > > > For the sake of this and future discussions, let me mention that one of > SLF4J's > main selling points is its simplicity. Compared to JCL, SLF4J way of > binding to > the underlying logging system is outrageously simple. It covers fewer use > cases > than JCL. But, as SLF4J is simpler it is also more robust and as you > pointed > out, robustness must be an essential characteristic of a logging framework. > In > short, simplicity of implementation matters. > To quote Albert Einstein: "Make everything as simple as possible, but not simpler." I *love* the way SLF4J/logback binding is done. The same is the case for the xxx-over-slf4j stuff. > More to the point, the bug under consideration is not insidious. If a > client has > cyclical arrays and attempts to log them, their application will crash > immediately with a clear pointer to MessageFormatter.deeplyAppendParameter. > They Hehe, are you really sure about this? Granted, I would do that. And you would do that, too, if you had a problem like this in some library you're using... but I know several developers that would be *sure* that the problem must somehow be their fault, searching hours and hours, while the logging they would need to analyze the problem would be broken ;) I suggested slf4j and logback to a certain guy at TU Darmstadt so quite some very fresh students with very limited experience are using it right now to log their very first java programs... > > will complain about the lack of support for cyclical arrays and we will > quickly > provide a fix. Here, I am assuming that non-cyclical arrays during > development > do not suddenly become cyclical in production. So instead of supporting > cyclical > arrays today, we can provide them tomorrow, but only when a user asks for > it. > This is just an application of the "1$ Today Is Worth More Than 1$ > Tomorrow" > principle -- avoiding adding features that users don't seem to need today > and > hence saving a few cycles of my development time and more significantly a > few > brain cycles of people trying to read SLF4J code. > I understand your point. Feature creep can be a big problem... In my opinion there are roughly three kinds of bugs. I'll give you an example for every one: 1.) Bugs like this one or the original recursive Marker problem that could result in an application crash, no matter how likely or unlikely the scenario for the crash is. They need to be fixed, ASAP, after identification of the problem and after writing a unit test, of course. I would not call the prevention of a crash an additional feature but a fix of a defect instead. Those are, in my opinion, showstoppers. 2.) A problem like the one I described in my last comment at http://bugzilla.slf4j.org/show_bug.cgi?id=76 This is a situation where I see a problem lurking in the future. I tend to fix such problems anyway just to get them out of my head and prevent future troubles. Chances are that I won't have very much time to spare when such a problem manifests so I'll fix them when I stumble over them. 3.) An inconsistency like http://bugzilla.slf4j.org/show_bug.cgi?id=93 I don't really care if this behavior is changed or not. I just wanted to let you know - so that you *do* know. I, personally, like consistency but this "bug" is really irrelevant. No harm can be done by this problem. To quote The Pragmatic Programmer: "Don't leave broken windows." Concerning bugs like 1.) I'll now try to argue from a different direction: If slf4j/Logback would tear down our web application which is supposed to be online 99.9% then I would be the one with the "chopped off head" because I was the one that suggested the transition away from commons.logging and log4j over to slf4j/log4j and later slf4j/logback. While the chopped off head is surely an exaggeration there are a lot of people that are quite dependent on the proper function of slf4j right now. So this is also a story about trust. People trust you. Every bug that manifests in an actual application removes a little bit of trust so it's always a good thing to fix a bug *before* it's actually doing harm to someone. I'm not sure about the $1 metaphor in that case. And last but not least, concerning "we will quickly provide a fix": I submitted http://bugzilla.qos.ch/show_bug.cgi?id=148 in April, including a suggested fix, and it hasn't been included into logback yet, neither was there a new version of logback since March. This isn't meant as criticism at all. Really ;) I just wanted to use it as an example that "quick" can be quite relative. > However, as you observed, the fix is simple and elegant, so there is no > point in > procrastinating the implementation of a simple solution. > > Thank you. Again, as I said in previous mails, I hope you don't get me wrong as I'm essentially a big fan of your software. I'll stop making remarks about that from now on, ok? ;) English isn't my first language so there is a certain possibility that something might sound harsh even though it's not meant to be that way. Regards, Joern.
_______________________________________________ dev mailing list [email protected] http://www.slf4j.org/mailman/listinfo/dev
