"nemesis" <nam### [at] gmailcom> wrote:

> We should not forget povray is heavily used by non-programmers and adding
> more stuff -- like more syntax items or heavy-handed standards -- may put
> some of these people down...

I think I've got it!

In our ini files, each of us has default settings for variously-leveled
parameters:
image resolution, render quality, antialias tolerance, etc.

Why not have a tiered system whereby each user can establish how strictly or
loosely they want there includes governed?

Then, when the collection is up-and-running, the subgroups in the collection
could reflect the include regulator levels in the ini file.

If someone with strict standards really wanted to use something from a more
casual source, then it's caveat emptor.

Also, I think that the "#include ... #as" idea is more dynamic and flexible
than the #namespace approach.

-Randall

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> Today, when I #include a file, its declarations may conflict with previous
> ones.  When such a thing happens, povray should *warn* the user and suggest
> using an alias for the included file and access its contents via the alias.
>

My worry would be about files that are expecting to see a global variable by
one name and get the prefixed version instead.  It seems like the scope of
#as would have to cover any files that the #included file depends on.

Charles

Post a reply to this message

"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