T.J. Duchene wrote: > Didier Kryn wrote: > > > > What are your preventions against OOP for graphics? Is it against OOP > >in general? > Mostly against OOP in general. It wasn't a bad idea to start with, but OOP > started out with good intentions and blossomed more into a movement. The > question really is has OOP made code easier to maintain and less complex. > Generally speaking, the answer is not really. The primary reasons for using > OOP are encapsulation, polymorphism and inheritance. > > Yes, encapsulation in scope is a good thing, but much of that can be > achieved in other ways without using objects. When you take languages like > C++, while the language itself is standardized, the name mangling that the > compilers introduce is not standardized at all. That makes prepackaged > libraries and sometimes linking questionable unless you are using the same > version and compiler. It is enough of a problem every version of Linux > recommends not updating your installation piecemeal (eg if I update XFCE, I > better recompile everything that is linked to XFCE - even if everything is > backward compatible). Microsoft got around it somewhat by using their COM > specification. > > Polymorphism? Yes, I will agree that polymorphism is helpful. That can be > achieved with things like pointers, void arrays, and in the case of C11, > the use of _Generics. > > So that leaves inheritance as the last real standing benefit of OOP, and > that is really the one everyone hates. Most OOP languages limit inheritance > to single instance in order to avoid some very bad problems. Realistically > 90% of the time, it is better to not inherit at all, but simply instantiate > what you would have used as a base class as a variable class inside of your > class, and then dispose of it when you are finished. You have no problems > with multiple inheritance, calling base functions, and overall you are > wasting less of the stack and memory. > > The major reason I object to OOP is exceptions. They make it impossible to > write code with 100% predictable exit points. When code can exit at any > point above and below your own, that means that things can leak. "Add a > garbage collector," you might say. What happens when the collector has a > flaw and you do not know about it? Leak again.
Hi T.J. and others, I've been following this thread with some interest. T.J., it seems most of your objections to OOP are not strictly against the principles and advantages of OOP in abstract, but against the way OOP is implemented in C and C++. As a programmer in a dynamic garbage-collected language, I find most of these objections don't apply. I have experience writing and then refactoring a medium-size application in Perl to OO. It was quite a long process, to be honest. If I did it again, I would have spent more time developing tests. Fixing and breaking and fixing again based on user bug reports has been somewhat tedious, ameliorated to some extent by good logging facilites and stack backtraces on fatal errors. While I might be able to develop similar code without objects now that I understand OO ways of thinking, I feel no reason *not* to enjoy the syntactical, organizational and cultural advantages of OO coding. Constructors and destructors are a helpful convention to ensure objects get initialized and cleaned up properly. The $object->method() syntax is a great organizing principle. I know where to look for methods, usually in the same file as the constructor/destructor and other aspects of the class definition. Code related to each class goes into separate namespaces. At the risk of sounding like an enthusiastic newbie, it is so awesome! Working on an application that has grown to about 20k lines, OOP is the only way I've been able to manage. I've followed the debates about inheritance, and used inheritance a lot. I haven't had a chance to try out the major alternative to inheritance in OOP: roles. However, I have read blog posts of a programmer working for the BBC who managed to flatten a huge codebase with hundreds of classes and an incredibly complex inheritance tree, into fewer classes that consume roles. In my case, inheritance means that, in the DAW application I've been developing, I can have audio Track objects, and I can easily modify them for a special case where I need to override some behaviors. I even have separate user interface classes, so that users can have a GUI, a terminal interface or both together. Each time I introduced a class, I got rid of numerous if statements that had been sprinkled around. So for me, with my limited experience, OOP is the greatest thing since sliced bread. There are many situations where I don't use OOP, but where I need it, the advantages are immense. I'll take any computer science innovations that can help me, whether its objects, grammars, exception handling, testing or version control. Each brings new possibilities for bugs, and overhead to develop and maintain, but I think there are good reasons people value these innovations. Perhaps I misunderstand your complaints, or perhaps I'm fortunate to be using a language where those complaints are less applicable. Perl is currently blessed/cursed with many object frameworks, and it appears there is a lot of work finding how to get the most benefit for the least pain. So while it's still being hashed out, I think no one in the Perl, Ruby or Python communities who knows how to use OOP would willingly give up this paradigm. Again, it's been interesting to read your take. Please keep on posting! Cheers, -- Joel Roth _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
