Re: [logging] ECL: Log interface vs. abstract class

2004-12-26 Thread Richard Sitze
Simon Kitching [EMAIL PROTECTED] wrote on 12/25/2004 06:25:51 PM: On Mon, 2004-12-20 at 18:28 +0100, Ceki Gülcü wrote: In my last message, I failed to emphasize the brittleness of the break into interfaces hypothesis. Even if at a high-level of abstraction two APIs perform

Re: [logging] ECL: Log interface vs. abstract class

2004-12-25 Thread Simon Kitching
On Mon, 2004-12-20 at 18:28 +0100, Ceki Gülcü wrote: In my last message, I failed to emphasize the brittleness of the break into interfaces hypothesis. Even if at a high-level of abstraction two APIs perform the same task, this does not mean that they can be abstracted away by

Re: [logging] ECL: Log interface vs. abstract class

2004-12-25 Thread Matt Sgarlata
Simon, I agree with you 80% and I think you're right that JCL should stay as-is for now. I think you're dead-on with this new line of thinking. It won't seem like it because now I'm going to spend the rest of this email disagreeing with you, but I'm with you on the big leap you took in your

Re: [logging] ECL: Log interface vs. abstract class

2004-12-21 Thread Henning P. Schmiedehausen
Ceki =?iso-8859-1?Q?G=FClc=FC?= [EMAIL PROTECTED] writes: all the attempts made at bridging X.25 and TCP/IP, both well defined and stable protocols, have failed miserably, even if both stacks supposedly fit into layers 1-4 of the 7 layer OSI network model. But X.25 and TCP/IP use two

Re: [logging] ECL: Log interface vs. abstract class

2004-12-21 Thread Ceki Gülcü
Henning, Thank you for sharing your mind. You have the right to pooh-pooh my opinions as much I have the right to express them. I still happen to think that the X.25 TCP/IP analogy bears relevance to the discussion. The fact that a simple analogy was sufficient to push your

Re: [logging] ECL: Log interface vs. abstract class

2004-12-20 Thread Ceki Gülcü
Whether you choose Log to be an interface or an abstract class does not really matter. The point I am trying to convey is that jcl will not be able to abstract more than one logging API. Although desirable, abstraction is not technically feasible. At 12:59 AM 12/20/2004, Matt Sgarlata wrote: I

Re: [logging] ECL: Log interface vs. abstract class

2004-12-20 Thread Ceki Gülcü
Aren't you assuming that things can be placed in nice orthogonal and independent boxes? Let X and Y be logging APIs that JCL attempts to abstract. Let IX be an interface unique to API X. Let JCL-IX be JCL's mirror of interface IX. If the end-user sprinkles her code with JCL-IX calls, there are two

Re: [logging] ECL: Log interface vs. abstract class

2004-12-20 Thread Ceki Gülcü
In my last message, I failed to emphasize the brittleness of the break into interfaces hypothesis. Even if at a high-level of abstraction two APIs perform the same task, this does not mean that they can be abstracted away by a thin facade (or bridge). For example, all the attempts

Re: [logging] ECL: Log interface vs. abstract class

2004-12-19 Thread Matt Sgarlata
Ceki Gülcü wrote: Log4j version 1.4 or 2.0 is likely to introduce the notion of multiple domains for categorizing logging statements. When that happens, the notion of logging levels will be looked at very differently. Commons-logging promises to abstract different logging APIs such as log4j,

Re: [logging] ECL: Log interface vs. abstract class

2004-12-19 Thread Matt Sgarlata
Ceki Gülcü wrote: Log4j version 1.4 or 2.0 is likely to introduce the notion of multiple domains for categorizing logging statements. When that happens, the notion of logging levels will be looked at very differently. Commons-logging promises to abstract different logging APIs such as log4j,