Sabrina - Thank you for your response

Sabrina Kilian <ykg### [at] vtedu> wrote:
> Why extra work for the author? If the library/include is prefixed, the
> author of any given scene doesn't need to prefix their work. It would be
> extra work for the library maintainers, however. A simple perl script
> should be able to locate any variables #declared in separate files. I
> don't know perl too well, but I'll see if I can cook up something anyways.

I am not addressing file names here - just their contents - the '#macro's
and '#declare's you want to import to your scene.

> If you mean local in the same sense as the #local command, what happens
> with collection includes like stones and shapes.inc? Making the user
> include each subfile just to have access to it seems like a good way to
> increase parse time and annoy the user.

By 'local' I mean the local interface between a top-level file - be it a
scene or another include file - and the set of files it immediately
'#include's.

The visual/tactile metaphor I have in mind is a 'membrane'.  On the input
side of the membrane is the 'declaration space' of a file's include files.
The 'declaration space' is the set of objects and such defined by "#macro
foo() ..." and "#declare bar = ...". On the output side of the membrane is
the 'implementation space' of the file the author writes - be it another
include or a scene.  The 'implementation space' is the set of code snippits
that make use of aforementioned 'foo' and 'bar'.

A given collection of 'foo's and 'bar's is what I think of as the 'membrane
namespace.'  In the model I propose, a namespace would be 'local' to a
membrane.

A scene file has only an 'input membrane' (assuming it includes other
files).  A raw-code-written include file has only an 'output membrane'.  An
include file which '#include's other files has both an 'input membrane' and
an 'output membrane'.  In the model I propose, declaratives would be
prevented from migrating from an include file's input membrane to its
output membrane.

> This isn't really limited to the library project but POV in general.

Yes, exactly.  One of the questions I asked myself is "How do you accomodate
a large includes library without dramatically changing the way people use
POV-Ray?"

> Let's see where the conversation leads.

Yes, I am curious too.

-Randall

Post a reply to this message