"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> I do kind of think
> in terms of "objects" when using Pov-Ray, but I wouldn't call that "OOP
> (= Object
> Oriented Programming) thinking", even if that phrase means
> anything--which I doubt.

Well, I do agree that "OOP thinking" is somewhat fuzzy.

Let me rephrase the whole smash like this:

What others call "OOP thinking" might be more familiar to you than you may be
aware of.


> It might be more accurate to say that I am writing code which conforms
> to the syntax dictated by
> the SDL -- regardless of what kind of thinking leads to it. As I have
> said several times before:

> I think the concept of "object" is a real advance in programming but
> "OOP" seems
> a lot more than simpling making use of "objects" which "contain" both
> data members
> and functions ("methods")

Yes; what you describe would be "encapsulation", which is just one major
building block of OOP. As I mentioned earlier, another important one is
"polymorphism", which you can think of as the ability to equip multiple
different objects with methods that have the same name and parameters, but
different code to match the object's data structure. An example is POV-Ray's
"sphere", "box" and all the other primitives using the very same syntax to
transform, apply textures, etc.

A third concept frequently encountered in OOP, "inheritance", on the other hand,
is in my eyes not really an essential part of OOP, but instead just a mechanism
(albeit a powerful one) to manage issues arising from polymorphism, both
regarding redundancy (different objects may be similar enough that parts of
their data structures and methods can be implemented in the very same way, so
it would be a waste of time to write and maintain that same code twice) as well
as object compatibility (compile-time detection of potential attempts to invoke
methods on objects that don't have them).

Atop of this are a bunch of design patterns which are associated with OOP,
probably for the sole reason that they're making such heavy use of
encapsulation and polymorphism that it would be extremely cumbersome to express
them in a non-OOP language.

Some other stuff often associated with OOP languages just happen to have become
popular in mainstream languages at the same time as OOP; for instance
"overloading" of functons (defining multiple functions of the same name but
with different parameter types); model-view-controller architecture (dividing
an application into three components referred to as model, view and
controller); to name a few examples.


>
> >you only know how
> > typical end results from such thought processes look like, when formulated in a
> > general-purpose language retrofitted to better support such formulations
> > ("better" as in "better than nothing") - a language which, by the way, would
> > surely happen to be unsuited for a POV-Ray SDL.
>
> This seems to be true, where would I find some *real* OOP to look at?

I don't know whether there exists such a thing as "real OOP to look at".
Whatever code you look at, if you're not familiar with the language you'll
probably see more of the language's peculiaritis than you'll see of the
programmer's original thoughts.

Academic languages are peculiar anyway; and non-academic languages tend to
accumulate traits over time that are peculiar because the original language
didn't have them.

In the case of POV-Ray, I still have to come across some language that wouldn't
outweigh the benefits by its peculiarities. The current POV-Ray SDL is so
well-suited to its basic task that it would be imprudent to go very far from
that, as far as the effective syntax is concerned. The only problem with it is
that it is particularly ill-suited for the non-basic tasks people want to use
it for these days. It is exceptionally good for *describing* a scene, but also
exceptionally bad for *generating* it (which doesn't mean it lacks the power;
being Turing-complete, you can do anything with the currend SDL; but what it
does lack is performance, some more consistency, and some more support for
OOP).

So what I'd go for is a language that is deliberately designed to be very
remniscient of the current SDL when it comes to describing scene elements, and
as straightforward when it comes to simple scene-generation tasks (like, say,
placing 100 spheres in a row) - any language imposing some overhead for these
two would be ill-suited for POV-Ray.

Post a reply to this message