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 <aj@humbug.org.au> <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
Attachment:
pgpebxkbkhZND.pgp
Description: PGP signature