OK, as an offshoot from another thread here, perhaps an even simpler 
solution to the problem exists.  What if, everytime you #declare an 
object which has already been #declare'd, the parser gives you a warning 
telling you what was re#declare'd and where?

This would not apply to #local items, only to globals.  It would take 
some work to convert a lot of the current include files, but it would be 
much safer overall.

...Chambers

Post a reply to this message

Ben Chambers <ben### [at] pacificwebguycom> wrote:
> OK, as an offshoot from another thread here, perhaps an even simpler
> solution to the problem exists.  What if, everytime you #declare an
> object which has already been #declare'd, the parser gives you a warning
> telling you what was re#declare'd and where?
>
> This would not apply to #local items, only to globals.  It would take
> some work to convert a lot of the current include files, but it would be
> much safer overall.
>
> ...Chambers


file this idea under that thread too, Ben. :)

but then, suppose this works:  people actually look at the warnings if
things go noticeably wrong.  What happens next is that they will have then
to rename some stuff in their own files or, if they are out of luck, in
someone else's file if they include 2 or more files which happen to share
some names but are not related.

This is too much of a problem and a simple alias together with the include
declaration in the first place would not permit that to happen.  Giving a
unique prefix identifier of your own to include files is much better than
having to go through the files renaming stuff.  That and local scoping for
included items should go a long way into making povray SDL a lot more
sturdy and capable for handling large catalogues of objects and textures...

Post a reply to this message

Ben Chambers <ben### [at] pacificwebguycom> wrote:
> OK, as an offshoot from another thread here, perhaps an even simpler 
> solution to the problem exists.  What if, everytime you #declare an 
> object which has already been #declare'd, the parser gives you a warning 
> telling you what was re#declare'd and where?

#declare Index = 0;
#while(Index < 10000)
  #declare TheObject = sphere { <Index, 0, 0>, 1 pigment { rgb 1 } };
  ... (do something with TheObject) ...
  #declare Index = Index+1;
#end

  How many warnings do you get?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> #declare Index = 0;
> #while(Index < 10000)
>   #declare TheObject = sphere { <Index, 0, 0>, 1 pigment { rgb 1 } };
>   ... (do something with TheObject) ...
>   #declare Index = Index+1;
> #end
> 
>   How many warnings do you get?
> 

#local index = 0;
#while (index < 10000)
   #local TheObject = sphere { <index, 0, 0>, 1 pigment {rgb 1} };
   ... (do something with TheObject) ...
   #local index = index+1;
#end

No warnings at all :)
That's why I said it would take some work to get a lot of the current 
include files to work with this; of course, the behavior could be 
switched off via a command-line option (or an ini file option).

Basically, you would only use #declare for items that truly need to be 
global in scope, rather than using it out of habit.  Of course, I also 
like the idea I put forward of container objects, but this seemed like 
an easier solution to implement.

...Chambers

Post a reply to this message

Ben Chambers <ben### [at] pacificwebguycom> wrote:
> Warp wrote:
> > #declare Index = 0;
> > #while(Index < 10000)
> >   #declare TheObject = sphere { <Index, 0, 0>, 1 pigment { rgb 1 } };
> >   ... (do something with TheObject) ...
> >   #declare Index = Index+1;
> > #end
> > 
> >   How many warnings do you get?
> > 

> #local index = 0;
> #while (index < 10000)
>    #local TheObject = sphere { <index, 0, 0>, 1 pigment {rgb 1} };
>    ... (do something with TheObject) ...
>    #local index = index+1;
> #end

> No warnings at all :)

  The problem is that my version is completely valid and there's nothing
wrong with it, and there's no reason why someone wouldn't write code like
that. Issuing ten thousand warnings on it makes no sense.

-- 
                                                          - Warp

Post a reply to this message

Hi!

> #local index = 0;
> #while (index < 10000)
>    #local TheObject = sphere { <index, 0, 0>, 1 pigment {rgb 1} };
>    ... (do something with TheObject) ...
>    #local index = index+1;
> #end

This is not always possible: Imagine calling a include file inside a
loop, where the include file uses a global variable that has to be
changed for every run:

#local index = 0;
#while (index<10000)
	#declare This_Is_Used_By_The_Include = Some_Function(index);
	#include "someinclude.inc"
	#local index = index + 1;
#end

You'll always have to rely to some extent on the 3rd-party programmer,
even if you use real OOP-languages like C++ or Java.


Regards,
Florian

Post a reply to this message

Warp wrote:
>   The problem is that my version is completely valid and there's nothing
> wrong with it, and there's no reason why someone wouldn't write code like
> that. Issuing ten thousand warnings on it makes no sense.

That's true, it IS completely valid, which is why the warnings could be 
disabled.  The real question is not what is valid now, but what 
practices would work best to discourage namming conflicts.

...Chambers

Post a reply to this message

Florian Brucker wrote:
> This is not always possible: Imagine calling a include file inside a
> loop, where the include file uses a global variable that has to be
> changed for every run:
> 
> #local index = 0;
> #while (index<10000)
> 	#declare This_Is_Used_By_The_Include = Some_Function(index);
> 	#include "someinclude.inc"
> 	#local index = index + 1;
> #end
> 
> You'll always have to rely to some extent on the 3rd-party programmer,
> even if you use real OOP-languages like C++ or Java.
> 
> 
> Regards,
> Florian

This is certainly possible now, however it goes back to the old practice 
of using an include file as a macro, rather than including a file once, 
and calling a macro inside of it.  IMNSHO, this practice should be 
discourage anyway, so I would consider it a bonus ;)

...Chambers

Post a reply to this message

Ben Chambers <ben### [at] pacificwebguycom> wrote:
> This is certainly possible now, however it goes back to the old practice
> of using an include file as a macro, rather than including a file once,
> and calling a macro inside of it.  IMNSHO, this practice should be
> discourage anyway, so I would consider it a bonus ;)

i double that! :)

Post a reply to this message

Florian Brucker nous apporta ses lumieres en ce 06/12/2006 14:13:
> Hi!

>> #local index = 0;
>> #while (index < 10000)
>>    #local TheObject = sphere { <index, 0, 0>, 1 pigment {rgb 1} };
>>    ... (do something with TheObject) ...
>>    #local index = index+1;
>> #end

> This is not always possible: Imagine calling a include file inside a
> loop, where the include file uses a global variable that has to be
> changed for every run:

> #local index = 0;
> #while (index<10000)
> 	#declare This_Is_Used_By_The_Include = Some_Function(index);
> 	#include "someinclude.inc"
> 	#local index = index + 1;
> #end

> You'll always have to rely to some extent on the 3rd-party programmer,
> even if you use real OOP-languages like C++ or Java.


> Regards,
> Florian
What HORRIBLE piece of code! Do that then wonder why your scene takes so much 
time to parse and why it gobbles up your memory. Beter to use a real macro.

-- 
Alain
-------------------------------------------------
Al Gore is proof that Tennessee has a sense of humor.

Post a reply to this message