In article <397F0286.85776D5C@itam.cas.cz>, Disnel <dis### [at] itamcascz> 
wrote:

> But what are POV #declares? They can be taken as references, I think.

I suppose they could be considered references...
You could create basic "types" by making certain base objects to 
inherit/copy from, just like you do in some of the include 
files(shapes.inc, for example). Members would be copied as well. In 
other words, objects inherit from objects, not from object types.
My idea doesn't separate types of objects and actual objects, like C++, 
but it should work, and might be much easier for people to learn. 
Besides, I don't see any simpler way of adding OOP to POV-Script.


> You are right with virtual methods, all would behave "virtual"

I don't see how they couldn't, since POV is interpreted all in one pass, 
and doesn't have separate compile-link-run stages. That, and the way 
it's "types" are done...


> For example I have two spheres and my new object, which connects
> these two spheres with cylinder. When one sphere was changed during
> animation, my connecting object need to be notified about it.
> Where it contains only copies of sphere, it knows nothing about
> change.

I still don't see the problem...have one sphere be changed with a member 
macro, which calls member macros of the other sphere and the linking 
cylinder. When one changes, the other two will be updated automatically. 
The main sphere is updated every frame of the animation, and all three 
are stored in persistent variables, say Sphere1, Cylinder, and Sphere2. 
After processing is done, copies of them are placed in the scene, like 
this:
Sphere1.Update(clock);

object {Sphere1}
object {Cylinder}
object {Sphere2}



> > If you mean adding members to an existing variable, then don't do that!
> > It would be like trying to add variables and methods to a C++ class.
> > Just make a new object from that one, which has the additional members
> > you need.
> 
> I don't mean anything else.

Just make a new variable/class with the new members, and using the same 
name as the parent object...like this:
#declare Foo = object {...}
#declare Foo = object {Foo ...new members...}
Where is the problem? You don't need to be able to add variables or 
functionality to an existing object, just create a new one derived from 
the original. What do you think inheritance is for?


> Here we don't understand: you are thinking about object oriented
> preprocesor and I'am thinking about object oriented scene during
> rendering and animation, I'am right?

No processing of the scene file is done during rendering...the scene 
*has* to remain static during that stage, and it wouldn't make sense 
otherwise. It makes sense to only modify objects which you have in 
dynamic form, as a variable. As for animation, the scene is reprocessed 
before every frame. You can keep variables from one frame to the next, 
what is wrong with modifying those and rebuilding the scene each frame?

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message