On Sat, 2007-02-03 at 17:58 +0100, Roland Weber wrote: > Hi Oleg, > > > I do not think we should try to be holier than the Pope. As far as I > > know Sun uses non-public Sun specific classes all over the place in > > JRE. > > If Sun's code were good enough, we wouldn't provide an alternative > HTTP implementation. Why should we sink to their level in other areas? > ;-) > > This morning I realized why I don't like the API<->Impl intermingling. > The software engineering classes I attended in the early nineties were > rather dull, but - apart from the "Chinese Principle" - there was one > golden rule I took with me, which was reenforced in other areas too: > Cyclic dependencies are bad. > The implementation necessarily has a dependency on the API, and by > letting API classes depend on implementation classes, we get a cyclic > dependency. Well, Sun has a cyclic dependency even between java.lang > and java.io, but that doesn't mean I have to like it. > Cyclic dependencies can't be avoided on a class level, since there > are no header files in Java. I'm used to avoid cyclic dependencies > on a package level in my code. For HttpComponents, I would be content > to avoid a cyclic dependency between the API and the impl part of the > source tree. I don't think that qualifies as "holier than the Pope". > But if it is unattainable, so be it. I've got so much refactoring > ahead of me, I don't insist on doing more. > > > We could make HeaderGroup and DefaultHttpParams public classes, or make > > then inner classes instead, but personally do not see a lot of value in > > doing so. Http service handlers in HttpCore NIO make a heavy use of > > buffering primitives that I do not think we want to support as a part of > > public API. Shall we make them all public, package private or inner? > > What's the difference between supporting something as part of the API > or as part of the implementation part? If there's a bug, we'll fix it. > If the class needs to be used by applications, such as DefaultHttpParams, > we'll keep the API stable in the implementation part too. In case of a > choice, I would rather move API classes to the impl part than vice versa. > > > We want people to be able to extend HttpCore and inject some application > > specific implementation of interfaces, but do we ever want anyone to > > provide a complete alternative implementation of HttpCore API? > > I doubt there will be one, whether the API depends on impl or not. > I just consider it an indication of a good design if API does not > depend on impl. But I've seen so many bad code, I won't loose sleep > over this topic if we get it right otherwise. > At the moment I can't tell how many dependencies we've got from API > to impl. Maybe I'll have a look at it after I finish the package > name change, which I'm about to tackle now. >
Hi Roland To me 'impl' in HttpCore means one and only thing: there is more than one way of doing it. We might be a little less picky about changing the inner working of those classes but I intend to support the interface compatibility of 'impl' classes exactly the same way as that of non-impl ones Let us fix it if we can, but I personally will not lose sleep over it, either. Cheers Oleg > cheers, > Roland > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
