In article <39061954@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom> 
wrote:

> 1) memory consumption.  If you #declare and then make an instance, 
> you have two copies of the object in memory.  One copy is created in 
> the symbol table when you #declare it.  The second copy is created 
> when you make an instance of the object.  The first copy remains in 
> the symbol table in case you want to make another instance.  If you 
> did this with too many objects (or just a few large objects) in a 
> scene, it would be very bad.

I don't see this as being a huge problem...you would get the same by 
#declaring the object, wouldn't you?


> 2) ambiguity.  Because there are two copies of object "MyBox", if you 
> tried to access an attribute of MyBox, which would it access -- the 
> copy in the symbol table or the copy in the scene.  That one might be 
> a bit too easy to answer, so what if you were able to modify "MyBox", 
> such as adding a new transform or texture -- then which copy would be 
> modified, and how would it affect past and future instances?

This is a bigger problem. I would say the variable is separate from the 
object in the scene, so you would always manipulate the one in the 
symbol table. Otherwise, you would sometimes be manipulating one of the 
in-scene copies(of which there could be many), and sometimes the one in 
the symbol table(when there aren't any in the scene). Future instances 
would reflect changes made.


> These issues could be resolved, but it would not at all be easy to do 
> so with the current POV code.  I ran into these same problems when 
> dealing with labels for persistent scenes for animations.

They would definitely be hard to fix...hopefully, during the C++ 
rewrite, these things could at least be planned for.

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

Post a reply to this message