On Mon, 25 Feb 2002 15:38, Rick Sivernell wrote: > 3. kde is no better, kdevelop puts in everything in there make.in and
it's actually one of the downsides of oops programming. while much is made of 'containers' and simply re-using code, it is the re-use that has (in my view) caused much of the bloat in kde. Perhaps a example will illustrate: Say for instance you create a widget class called balloon and it has, intitially two functions balloon.inflate() balloon.float() Later on, this code gets 're-used' by incorporating it in a higher level class so that the new balloon class has an extra function or two (in addition to previous) balloon.hold_water() Without going into the nitty gritty, the original code class is not touched modified, belted, buggered, tweaked with, or hacked. That is the beauty of oops programming and very appealing. Ie, the new hold_water function may have bugs but the older stuff works like it always did, you can't break it. (not without 'friends') Later on, the new balloon code (what's called an overloaded class), gets added to again balloon.colour() At this point, we have a class within a class within a class, all working nicely. Then, someone looks at the colour algorithm and decides it's damn useful, for other things. So, and this would be typical in the KDE scenario, the entire ballon classes plural, get grafted in to some program or other simply in order to use the colour function. Nothing else is used, it's redundant. This happens more often than you would think, and not because the programmer is an idiot but because the self documenting nature of c++ classes tend to hide from view the lower level functions that *might* be there. If you've ever looked at the QT class documentation, it takes a fair effort on your part to 'discover' what the contents of all the inhereted classes actually are. So at face value, the programmer uses the balloon.colour class for colouring because that's all the immediate documentation (header) says is in that class. Later on, this colour class gets added to balloon.darken_sprectral() you can see where this is heading. If you look at a fair chunk of kde code, and for that matter almost any large c++ program, you will discover as much as 80% of the class is NOT used for it's original definition. Imagine later on that the darken_spectral function becomes so appealing that the balloon class becomes balloon.mandlebrot_root() balloon.pythag() and so on. >From a simple class that inflates balloons, it has grown into a scentific calculator and the original code, while still there, is rarely, if ever, utilised. ----- As far as the Kdevelop spaghetti is concerned, I'm with you. It's jaw dropping stuff looking at the sheer amount of crud created for a 'hello world' program. The cause in this instance is because the developers have not fully understood the use of Wizards. Rather than be intelligent about what to generate, they take a boot's n all approach whenever a Wizard is invoked. And in point of fact, it harkens back to the C++ classes utilised, a lot of stuff is auto generated by underlying classes even though (most of) their 'hidden features' are irrelevant for the purpose at hand. A year ago, along with many other developers, I thought Kdevelop was the best thing since sliced bread and took to it with enthusiasm. I even put a few Kxxx applications 'out there' for public consumption A year later I'm back at the C foundry because for many uses, Kdev is simply too unwieldy. Also, it is a very tuff call to use the documenation feature (most Kxx apps are not documented because it's near to impossible to do so). That said, I like Kdev, because there's nothing else out there to like. Neither Gnome, nor Xfce, or any of the others, have an IDE to do the donkey work. -- http://linux.nf -- [EMAIL PROTECTED] _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Linux-users mailing list - http://linux-sxs.org/mailman/listinfo/linux-users Subscribe/Unsubscribe info, Archives,and Digests are located at the above URL.
