On Wed, May 19, 1999 at 10:03:12AM -0500, Ossama Othman wrote: > On 20 May, Anthony Towns wrote: > > One alternative that's probably worth considering is improving libdpkg, so > > that Apt and friends can make use of dpkg that way, and provide their own > > front ends however they see fit. > I don't think that is a "complete" solution. Improving libdpkg would > be good but, as Aaron described, that would just be adding/modifying > code to code that is already "brittle."
I was thinking more along the lines of `replacing', than improving. Basically, implementing the fundamental operations dpkg does as a library, then coding a simple, dumb dpkg(1) that links to that library but does little or no more than argument parsing itself. Having C++ wrapper classes around it for Apt and dpkg's convenience maybe, but being just another C-based library at heart. > > And I don't particularly think it's much of a gain to say "You want > > access to dpkg's internals? Just use C++!". C++ is all well and good, > > but it's not *that* good. > Hrm. I would have to disagree with you. Using object oriented > techniques certainly makes things easier to maintain, extend and debug. Oh sure, I've got nothing against OO design/analysis/programming. I don't even have all that much against C++ -- but I don't like the idea of locking any later apps into using C++ if it's /reasonably/ avoidable. In particular, if you find that you're not using too much inheritance/polymorphism for the core functionality of dpkg, you can get most of the benefits of OO programming without contorting C and friends all that much. But at least for the moment, I'm not doing any coding, so it's not my decision. Cheers, aj -- Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. PGP encrypted mail preferred. ``There's nothing worse than people with a clue. They're always disagreeing with you.'' -- Andrew Over
pgpVQ5qLDF3Q8.pgp
Description: PGP signature
