in news:456ec72e@news.povray.org Chris Cason wrote:

> Randall Sawyer wrote:
>> What if the contents of each include file be strictly limited to ONE
>> macro/object or ONE class of macros/objects/textures/etc? 
>> Furthermore, 
> [snip]
> 
> I'm inclined to go along with this, at least for macros/objects.

I think it will be restrictive quite soon when working on complex 
includes.

>[...] If it doesn't want to depend on another include for
> some other macro that the author already has but doesn't want to go
> to the trouble of releasing separately, then that macro (or
> declarations, or whatever) must be local to the file and not visible
> from outside, so as to not pollute the namespace and potentially
> cause collisions. 

how about the possibility of including 'packages' of includefiles. Think 
for example of Jaime's lightsys. It consists of several files and lots 
of macros and data. Now if we could just '#include lightsys' and in one 
go include all files in the directory /lightsys and put them all in the 
lightsys namespace, the potential of collisions gets a lot less. I'm not 
good at explaining this so maybe have a look at how Python deals with 
standard and third party libraries and namespaces. It's done very user 
friendly.

#include MMMM  (a library (directory) consisting of 7 includefile 
sharing a lot of code)

object { 
   MMMM.Parametric (
     function(u,v){R*sin(v)*cos(u)},
     function(u,v){R*cos(v)},
     function(u,v){R*sin(v)*sin(u)}
     <0, FromV(0)>, <pi, 2*pi>,
     20, 10, ""
   )
   pigment {rgb 1}
   finish{specular 0.3}
 }

Ingo

Post a reply to this message