In article <web.4577238990cd3dbce81faf070@news.povray.org>, 
sra### [at] yahoocom says...
> This is another off-shoot from a previous thread.
> 
> Currently, authors of POV-Ray files manage naming collisions themselves.
> They know the identifiers declared in their include files as well as the
> ones they write themselves.  Let's not try to fix what isn't broken.
> 
> What if an author wants to include a file which also includes still more
> files?  In that case - as POV-Ray exists now - unforseen naming conflicts
> may occur.  To address this issue, I propose the following concept:
> 
> Modify the parser in such a way that it assembles each include file as it
> goes.  Then, whatever identifiers were used to create the include file in
> the first place are available for reuse in any file which '#include's tha
t
> include:
> 
>     /-----------  B1 Names   /-----------
>     |  B1.inc  | ==========> |          |
>     -----------/             |          |  A1 Names   /---------------
>                              |  A1.inc  | ==========>
 | My_File.pov  |
>     /-----------  B2 Names   |          |             |  (or .inc)   |
>     |  B2.inc  | ==========> |          |            
 |{I cannot use |
>     -----------/             -----------/             |names used in |
>                                                       |B1.inc or used|
>                              /-----------  A2 Names   |in B2.inc.}   |
>                              |  A2.inc  | ==========>
 |              |
>                              -----------/             ---------------/
>     is transformed into:
> 
>     /-----------  A1 Names   /---------------
>     |  A1.inc  | ==========> | My_File.pov  |
>     -----------/             |  (or .inc)   |
>                              |{Now I can use|
>     /-----------  A2 Names   |names used in |
>     |  A2.inc  | ==========> |B1.inc or used|
>     -----------/             |in B2.inc.}   |
>                              ---------------/
> 
> I am uncertain as to the best means for implementing this idea.  I have
> already suggested one possibility though:
> 
> One way is to retroactively rename all of the identifier declarations in
> B1.inc and B2.inc and all of their corresponding implementations in A1.in
c
> uniformly.  Renamimg the identifiers would be done by the parser once the
> files are loaded into the buffer.  The parser would append each identifie
r
> string using character values that no user could with a keyboard (ascii
> 128-255).
> 
> I would appreciate some feedback.
> 
> -Randall
> 
Actually, the thing that would make the most sense would be to use 
something like procedure "scope". Each include can refer "directly" to 
it own names, but anything deeper needs to be "explicit" about what is 
used. Lets say you have:

fred.inc>
  #define abc blah1

jed.inc>
  #include fred.inc
  #define abd blah2

sed.pov>
  #include jed.inc
  #define abc blah3

Sed would need to "explicitly" ask for jed.fred.abc to use it.
Jed needs to "explicitly" ask for fred.abc.

The problem is, this "breaks" current implementation. Now, that doesn't 
mean you couldn't write a failure simply recursive system to "find and 
fix" such references, or even eventually design the editor to 
"recognize" them and automatically give you MS Studio style recall, like 
typing "jed." and having a pop-up list of thing "in" jed.inc, including 
fred.jed.<blah>. In other words, its not trivial, but hardly impossible 
to write a function like "Convert this scene and its includes to new 
naming system", and automatically fix all of it, saving the new files 
under slightly different names, to preserve the originals.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message