Re: PostgreSQL port to pure Java? - Mailing list pgsql-hackers
From | Thomas Hallgren |
---|---|
Subject | Re: PostgreSQL port to pure Java? |
Date | |
Msg-id | bra6lk$2sq$1@news.hub.org Whole thread Raw |
In response to | PostgreSQL port to pure Java? (Ivelin Ivanov <ivelin@apache.org>) |
List | pgsql-hackers |
My 2 cents... The C++ language is a horrible language from an OO perspective. Operator overloading, copy-constructors, templates, etc. can produce quite horrendous and inefficient results if used incorrectly. Having said that I must defend it some too. Using C++, you get inheritance, data-hiding, polymorphism, and namespaces. None of that is present in C. When used correctly, those mechanisms help greatly when creating safe, reusable, and pluggable code. Code that will become less error-prone than C code simply because it very effectively inhibits a huge number of errors that can (and almost always are) found in C code. No language provides magic pluggability in itself. But a language that supports OO semantics is a much better fit when such logic are designed than a language that doesn't. Pluggability implies interfaces. Interfaces are not intuitively created in C. I've been involved in quite huge C++ projects myself. One of the projects was actually to write an Object Oriented Operating System (embedded on M68K boards). C++ is excellent for this and I imagine the same would be true when writing a DB-engine. Some restrictions should be applied to make C++ "housebroken" such as: 1. Pass everything by pointer, never by &ref. This prevents accidental execution of copy-constructors. 2. Never ever allow operator overloading. Use true methods instead. Using op-overloading, the code might look elegant at first but after a while it degenerates and gets hard to undersand. 3. Refrain from macros as much as possible (it makes the code hard to understand and hard to debug.) Create inline methods instead if performance is an issue. Compare to Java where you actually have no preprocessor capabilities whatsoever. 4. Use templates very selectively, if indeed ever. 5. Have everything inherit from one common Object (so that collections etc. store a base type). - thomas -----Original Message----- From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Doug McNaught Sent: Thursday, December 11, 2003 15:24 To: Shridhar Daithankar Cc: Postgresql Hackers Subject: Re: [HACKERS] PostgreSQL port to pure Java? Shridhar Daithankar <shridhar_daithankar@myrealbox.com> writes: > Jokes and facts aside, I can't help it to think how better it would > have been, if postgresql was in C++. We could easily plug multiple > implementations of underlying subsystems without mucking much in base > code.. That's easy to do in any language if your code is carefully designed for it (look at the Linux kernel for an example in C) and hard to do even in C++, if the design isn't suited. So your assertion that C++ would have magically enabled "pluggabilty" doesn't hold water. > Wild thought anyways.. Indeed. -Doug ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html "Doug McNaught" <doug@mcnaught.org> wrote in message news:87n09zqvph.fsf@asmodeus.mcnaught.org... > Shridhar Daithankar <shridhar_daithankar@myrealbox.com> writes: > > > Jokes and facts aside, I can't help it to think how better it would > > have been, if postgresql was in C++. We could easily plug multiple > > implementations of underlying subsystems without mucking much in base > > code.. > > That's easy to do in any language if your code is carefully designed > for it (look at the Linux kernel for an example in C) and hard to do > even in C++, if the design isn't suited. So your assertion that C++ > would have magically enabled "pluggabilty" doesn't hold water. > > > Wild thought anyways.. > > Indeed. > > -Doug > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html >
pgsql-hackers by date: