In article <web.457745f5315c6ef0e81faf070@news.povray.org>, 
sra### [at] yahoocom says...
> Patrick - Thank you for your response
> 
> Patrick wrote:
> > 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, lik
e
> > typing "jed." and having a pop-up list of thing "in" jed.inc, including
> > fred.jed.<blah>.
> 
> I had been thinking along these lines before.  However, once I started
> asking myself the rhetorical question "What is POV-Ray?", I realized that
> the word "editor" does not appear in the answer.  POV-Ray - as it exists
> now - does not require the use of a specific editor.  To add that
> requirement to its use would make it more costly and less accessible.
> 
Umm. Not sure the idea is "That" serious. Sure, the "native" editor 
could be expanded to handle it, but I can code VB in notepad, just not 
with the bells and whistles available in the VB editor. We are talking 
about a GUI element that "helps" deal with a "language" specification. 
The editor used doesn't have to do that, but it does help things if it 
does. Its just means that someone using:

#include "fred.inc"

**must** treat anything in fred like fred.<blah>.

Its not going to make things any more complicated than trying to fix 
naming conflicts is already and, you could even make it so that the 
parser itself warns about conflicts, but "tries" to run anyway. I.e., if 
you don't have one, it uses the correct object anyway. If it does have 
one, it generates a warning about the conflict and what file its in, 
then tries to use the "local" named item. The only issue this causes is 
maybe needing to state me.<blah> or local.<blah> as a means to saying, 
"Yes, I **really** did intend to use the local one, so don't warn me."

> > 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.
> 
> What I am proposing would actually rewrite the deeper includes (those cal
led
> by other includes).  The rewriting would occur in the buffer - not in the
> files themselves, thus protecting the contents of the original includes.
> The rewriting would follow a fail-safe algorithm, applied the same way on
to
> every includes-tree.  There would be no need to "ask" to reuse an identif
ier
> from a deeper include.
> 
But, that doesn't do anything different than I suggest and it means 
**extra** time is taken "every" parse, to fix conflicts. Better to 
specify a system, then provide a means to update non-compatible scenes 
to the new standard.

-- 
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