glib dependancy in KDE3.x

[Stefan Westerfeld]

   Hi!

On Fri, Mar 07, 2003 at 06:14:00PM +0100, Guillaume Laurent wrote:
> On Friday 07 March 2003 17:04, Stefan Westerfeld wrote:
> > In fact, I am convinced that some things should be implemented in C. And I
> > am convinced that some things are implemented best using a main loop. Thus
> > I'd say that a user which commits himself to the irrational policy of using
> > only C++ applications and only C++ code, for the sake of attaining some
> > higher goal that I don't know of, should not be supported optimally by KDE.
> 
> You can't be serious here. "irrational policy of using only C++" ??

I am sorry ; as there already have been two misunderstandings on this, I will
try to describe what I mean in other words.

At some level of describing reality, every C application is a C++ application
already. This is because C++ is a superset of C. It has been designed
intentionally this way, to promote the reuse of code. 

This means that to increase code reuse, it is a good strategy to first consider
any piece of C++ and C code out there as C++ code. Thus, glib is C++ already.

Then, you can ask you in a second question whether you want to not use some
features of C++ in certain pieces of code. There are a few reasons why you
might not use certain features in some code:

 - extreme API/ABI stability
    -> no virtual inheritance
    -> no virtual functions
 - portability
    -> no exceptions
    -> no global constructors
	-> no excessive templates
	-> no STL
 - efficiency
    -> no virtual functions
	-> no inheritance
	-> no standard new/delete operators
 - extreme long-term API/ABI stability
    -> no inheritance
 - extreme portability
    -> no C++

Thus, for pieces of code mainly involved with portability, I think it is a
good choice (that glib made), not to use any C++ features, just as the linux
kernel did the same choice.

This is: I think C++ features should be used whereever they do more use than
harm, but in some cases, they do more harm than use. Thus, its irrational
to say: every piece of software that is written in C should be implemented
in C++, if you mean by this: you want to use and write all software in a way
that it does use all C++ language features, regardless of the task it was
designed to do.

On the other hand, I think if you make wise choices about which pieces of
software might make more sense to implement in C and which might make more
sense to implement in C++ (if you mean by this: to use certain language
features of C++, that C didn't already have), then I could not agree more
with you.

> > I think KDE should promote tolerance and understanding where we can, and
> > this is a place where we can promote understanding of what programming
> > languages and code sharing are really for.
> 
> How about promoting a working, stable desktop and development platform, 
> available in a limited amount of time ?

Right, I can stand behind this definition of what KDE is as well. But under
this definition, it makes sense to accept that glib is a good choice for
portability of C code, and not exclude C code from inclusion into KDE just
because it uses glib.

This "because it uses glib" argument hinders cooperation with GNOME, who are
working on the same goal as KDE already for years, and if we could cooperate,
then our limited amount of time would be more wisely spent.

Thus for implementing server processes (like aRts) which could be used by
KDE and GNOME, using glib isn't such a bad choice actually, I'd say. MAS
could consider it, too.

I don't mean to say that we should use gobject-2.0, though. GObject is IMHO
technically inferior to "real" C++ development, because a lot of reasons.
Thus, I am only planning to use those parts of glib that do bother with
keeping C code portable.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan at space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-