glib dependancy in KDE3.x

[Stefan Westerfeld]

   Hi!

On Thu, Mar 06, 2003 at 10:36:41AM +0100, Rob Kaper wrote:
> On Thursday March 6 2003 10:24 am, Alexander Kellett wrote:
> > i'm 100% for the addition of glibc therefore.
> 
> glibc != glib, though. ;-)
> 
> I am against using glib in KDE. We could've used Gecko, too, when it was ten 
> times better than kfm. If you can't do anything useful in C without glib, 
> perhaps C is not what arts should use?

I think your argument makes no sense, unless you're prepared to accept the
conclusion that C++ is inheritly superior to any other programming language.

I do think of programming languages as tools which help you to write portable
code (for instance processor independant). Thus, they abstract from certain
details, and emphasize others. There are different flavours of programming
languages with respect to how they handle control flow, what general paradigm
they follow, and so on.

Some of them are beneficial if you want to write highly efficient code, some
of them are beneficial to write object oriented code, some of them are
beneficial to write code based on deduction and unification, such as prolog.

Thus one should ask oneself what goals does aRts have:
 - high efficiency
 - high portability
 - concurrency (threading)
 - optimal signal processing
 - running as server process
 - object oriented interface

Some of these things indicate C as the optimal programming language, whereas
other indicate C++ as the optimal programming language. Fortunately C++ is
a superset of C, and thus aRts can be implemented in the optimal mixture
between both. However, for the efficiency, portablity and concurrency issues
that aRts has, already a C library has been written. Thus I am suggesting to
use this C library. It is called glib.

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