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