* Aaron Van Couwenberghe said: > Polymorphism is such an obvious pillar of structured programming that I > can't understand how anybody could live without it. Is it? AFAICS none of the traditional languages like Pascal or C has polimorphism at its base... > > In particular, there are established ways of linking programs written in > > any language against C based libraries. As far as I'm aware doing the same > > to C++ (or other object-oriented languages) is a pain in the neck. > > This is simply not true. > I have grown increasingly aware of FUD of this type about C++ and OO > languages. OO is designed to *increase* interoperability, flexibility, and > extensibility -- definately not the other way around. Yes, perhaps but in a C++ ONLY environment! Tell me how to link a C, Fortran, Cobol, whatever program against a C++ library? Or show me interfaces in scripting languages to use such C++ libraries? So, what you're saying is "simply not true"... C++ is really good language, but it is NOT interoperable with other languages. Period. And that makes writing such an important program as dpkg in C++ a futile task - because you'd have to force other programmers to use C++, and I can bet my salary that 80% of *nix programmers will swear by C and refuse to use C++... Are you ready to face it? > > 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. > > No, there are leaps and bounds to be made by this sort of organization. > Basically, any one feature or behavioural pragma need only be implemented in > one component; afterwards it's applicable to all future setups. And, once again, tell my why in heavens can't it be implemented in C??? So far not even single argument you used convinced me that C++ is the Right Thing(tm) in this situation. > This is another misconception about C++ and OO. First off, this type of > design is intuitive and fairly simple to achieve. It'll be more > maintainable, more flexible, and faster. Faster because not every single > program needing to open the database or launch dpkg will need to reread and > reparse the status/available databases a gazillion times each! (plug at apt > not meant personally to anyone ;P) Imagine something like this: 1. you create a C library with all the dpkg functionality inside 2. you compile and link it as a shared library 3. you write several simple drivers to interface the user to that library 4. the .so is loaded only ONCE - that's what shared libraries are for ergo, I still can't see anything in favor of C++ here... No apparent advantage save for the design-time clarity - and that can be achieved in C as well while still giving a fast, compact and INTEROPERABLE library/program > > > Whether or not the community approves of this, > > > I will pursue it, and let the chips fall where they may. > > > > Good luck, FWIW. I've no doubt you'll need it. > > As far as writing it, no. As far as getting something like this accepted, Oh, so you say it's a piece of cake to write it? Well, I'm sorry, but it seems a little bit arrogant to me... (no offence intended) P.S. Just in case: please, let us all stay calm, ok? :)))) marek
Attachment:
pgphXeOe7bGS9.pgp
Description: PGP signature