"Charles C" <nomail@nomail> wrote:
> My worry would be about files that are expecting to see a global variable by
> one name and get the prefixed version instead.

but the alias is given by the user of the include file in his own file.  So,
the prefix is necessary and he is well aware of it, since it was him who
named it in the first place.

> It seems like the scope of
> #as would have to cover any files that the #included file depends on.

perhaps an example could illustrate the situation better?

Post a reply to this message

Re: #include ... #as

Assuming that every include file's name is unique, then the real concern is
the names of the #macros and #declares within.  What about some sort of
name registration process along the lines of domain-name registration?

Once an include is accepted, then the names of its #macros and #declares are
nolonger available within later include files.

One approach which might make this process more manageable, would be to
require that each #macro/#declare name contain an abreviation which
identifies the type of object it returns ( light_source => foo_ls, texture
=> foo_tx, CSG => foo_cg, mesh => foo_mh, etc.).

-Randall

Post a reply to this message

nemesis wrote:
> "Charles C" <nomail@nomail> wrote:
>> My worry would be about files that are expecting to see a global variable by
>> one name and get the prefixed version instead.
> 
> but the alias is given by the user of the include file in his own file.  So,
> the prefix is necessary and he is well aware of it, since it was him who
> named it in the first place.
> 
>> It seems like the scope of
>> #as would have to cover any files that the #included file depends on.
> 
> perhaps an example could illustrate the situation better?
> 
> 
> 

If I understand correctly, the proposed #as would do what, add a prefix
to everything that the include makes available to the outside?

Okay, there would be two ways of handling the following:

#include "nem_bike.inc" #as nem // bike by nemesis

Everything in just bike.inc is prefixed with nem. If bike.inc includes
another file, are those prefixed or not? If not, we run the risk of name
overlap again because those items are probably going to be less likely
to be checked. If they are, how will bike.inc know what variable names
to call?

Will #as tags stack like namespaces, or when a new one is created is the
last one automatically closed?

Post a reply to this message

"Randall Sawyer" <sra### [at] yahoocom> wrote:
> One approach which might make this process more manageable, would be to
> require that each #macro/#declare name contain an abreviation which
> identifies the type of object it returns

yes, yes, i believe this kind of "Hungarian Notation" is used by most
povvers.  But if we require that each include file #declare gets prefixed
by a unique identifier, we'll endup with limits to the number of include
files and it is indeed too confusing.  Why can't i call my make_bike macro
simply make_bike within my own include file?  Just because the name will
clash with someone else's make_bike?  This is why i like aliases, since
they allow us to decide what to call someone else's #declares...

Post a reply to this message

Sabrina Kilian wrote:
> If I understand correctly, the proposed #as would do what, add a prefix
> to everything that the include makes available to the outside?

FWIW, in my experience, by the time the conversation gets to this level, 
progress has stalled to the point where nothing will get done because 
it's never perfect enough to start. Given that there isn't, at this 
time, any sort of problem along these lines, and given that the 
repository is a source-code repository with a license that allows such 
things to be fixed if it becomes a problem, it's probably better to get 
started, rather than to wait for POV-Ray to be improved to the point 
where a giant repository could be compiled without assistance.

-- 
   Darren New / San Diego, CA, USA (PST)
     Scruffitarianism - Where T-shirt, jeans,
     and a three-day beard are "Sunday Best."

Post a reply to this message

Perhaps a better solution, to avoid both namespace collisions and 
automatic name mangling, would be to add a new object type, the 
'container'.  It would work something like this:

#declare stuff = container;
#declare stuff.x = 5;
#declare stuff.loc = <3,4,6>;
#declare stuff.ball = sphere {0,1}

Basically, the container acts as a namespace on its own.  Each include 
file could use a container for its variables and declarations, except 
for those it needs exported globally.

...Chambers

Post a reply to this message

From: Sabrina Kilian
> If I understand correctly, the proposed #as would do what, add a prefix
> to everything that the include makes available to the outside?

Prefixing should be an easy option than to actually mess with povray's
parser to really cope with lexical scoping.

> #include "nem_bike.inc" #as nem // bike by nemesis
> Everything in just bike.inc is prefixed with nem. If bike.inc includes
> another file, are those prefixed or not?

If bike #includes a file and gives it an alias, that alias should actually
be of #local scope.  So, the #included items should only be visible inside
bike.inc.

Perhaps you're making confusion between #including bike's contents to your
file and the contents bike.inc #includes from other files?  The latter
should not be visible outside bike.inc.  I'm guessing povray's parser
could give a help by handling it transparently like:

/* bike.inc */

#include "nuts_and_bolts.inc" #as nuts

This would be handled by povray's parser as follow:  create in bike.inc
prefixed #locals for each #declared items in nuts_and_bolts.inc.  Will it
work?  I don't really know, but it's an idea.


From: Darren New
> FWIW, in my experience, by the time the conversation gets to this level,
> progress has stalled to the point where nothing will get done because
> it's never perfect enough to start.

Yes, i agree.  But give it some more time for more people to have some input
into this discussion.  Some planning can never hurt, only if remains just
planning...

> it's probably better to get started, rather than to wait for POV-Ray to be
> improved to the point where a giant repository could be compiled without assistance.

I'm also eager to get it going! :)


From: Ben Chambers
> Perhaps a better solution, to avoid both namespace collisions and
> automatic name mangling, would be to add a new object type, the
> 'container'.  It would work something like this:

#declare stuff = container;
#declare stuff.x = 5;
#declare stuff.loc = <3,4,6>;
#declare stuff.ball = sphere {0,1}

hmm, whatever happens if i #include a file that #declares a "stuff"? :)

> Basically, the container acts as a namespace on its own.  Each include
> file could use a container for its variables and declarations, except
> for those it needs exported globally.

Actually, your container looks remarkably similar to an "class instance"...
but, how is the container any different from a #macro?  They look the same,
except you have to prefix each variable with the "macro" name.

Post a reply to this message

hello, here's some more food for thought regarding aliased includes:


/* test.pov */
#include "test1.inc"


light_source { 4-8*z 1 }

object { test1_sphere
        //texture { t_sph }
        //texture { test2_t_sph }
        translate z*5
}

/* test1.inc */
#include "test2.inc"

#local test2_t_sph = t_sph // <- *1* povray parser makes included declare
local to this file...

#declare test1_sphere = sphere { 0, 1
        texture { test2_t_sph } // <- ... we use it prefixing with our
chosen alias ...
}

#undef t_sph // <- *2* ... and undef all included #declares at the end


/* test2.inc */
#declare t_sph = texture {
        pigment { rgb y }
        finish { diffuse .6 phong .9 phong_size 50 }
}


It works well. If you uncomment the given textures in test.pov, it won't
render, since the symbols are hidden as expected.

So, if povray's parser gives us a help in making steps *1* and *2* a
reality, we can get better symbol scoping with very little effort.

Post a reply to this message

As I've shared before, I am a hands-on learner.  So, I have set up an actual
scenario for myself to experiment with.  I would also like to share it with
all of you.

I am posting an attachment at povray.binaries.scenes-files (look for
Standards Challenge).  It is a folder called "SRS.StandardsChallenge".  In
the folder are three files: "povver1.inc", "povver2.inc" and "scene.pov".

In the first file, there are definitions for the #macros "ball", "rod" and
"block" as well as a definition for the macro "p1_donut".

The second file contains definitions for the #macros "ball", "rod", "block"
and "p2_donut".

The scene file calls the #macros "ball", "rod", "block, "p1_donut" and
"p2_donut".
By reversing the order of the two #include lines in "scene.pov", you get a
different result.

The challenge is to use existing POV-Ray SDL to modify the three files,
presenting them as two (rewritten) *.inc files and eight *.pov files - one
for each possible outcome.

Post a reply to this message

Solution to Challenge:  Is it generally extensible?

You can download my solution to my own challenge at aforementioned site.

Here is what I came up with:

In "povver1.inc":
    On the first line:
        // Use #declare whose = "povver1"
    On the two lines immediate preceeding any #macros or #declares:
        #ifdef ( whose )
            #if ( !strcmp(whose, "povver1") )

        *** macros and declares go here ***

    On the two lines immediately following any #macros or #declares:
            #end//(whose = "povver1")
        #end//ifdef(whose)

In "povver2.inc":
    The same as in "povver1.inc", replacing "povver1" by "povver2"

In any scene file:
    #declare whose = "povver1"
    #include "povver1.inc"

    stuff from "povver1.inc" you want to have in scene - modified or not

    #declare whose = "povver2"
    #include "povver2.inc"

    stuff from "povver2.inc" you want to have in scene - modified or not
    [ Nothing unique to "povver1.inc" file is lost, making it possible to
combine items from two-or-more include files. ]

Additional added value to this approach:  Author recognition!
By requiring that every include file make use of '#declare whose', a
scene-writer will be making an acknowledgement of the original author from
whom
they are borrowing.  It will be written into the text of their scene file.

Will this work?  Is there something I'm missing?

-Randall

Post a reply to this message