POV-Ray : Newsgroups : povray.object-collection : Compliance: local variable scope Server Time
29 Mar 2024 07:38:16 EDT (-0400)
  Compliance: local variable scope (Message 1 to 4 of 4)  
From: SharkD
Subject: Compliance: local variable scope
Date: 8 Jul 2008 17:40:00
Message: <web.4873de0a2d11efca5d2e82c0@news.povray.org>
In order for an object to be compliant, can I simply change all the variables in
the include file to local scope? Or, must I also rename them all using the
object's abbreviation?

I'm guessing that best practices is to do both.

-Mike


Post a reply to this message

From: Chris B
Subject: Re: Compliance: local variable scope
Date: 8 Jul 2008 19:10:05
Message: <4873f3cd$1@news.povray.org>
"SharkD" <nomail@nomail> wrote in message 
news:web.4873de0a2d11efca5d2e82c0@news.povray.org...
> In order for an object to be compliant, can I simply change all the 
> variables in
> the include file to local scope? Or, must I also rename them all using the
> object's abbreviation?
>
> I'm guessing that best practices is to do both.
>
> -Mike

The main objective is to avoid collisions with names chosen by someone using 
your include file, so in theory either would normally suffice and could be 
considered compliant. On the other hand, I've started using the unique 
prefix for the names of all identifiers (even local ones) because I noticed 
some circumstances where it removes some less usual potential conflicts.

Normally someone using your include file would simply include it in their 
own higher level scene file which should make using identifiers in your 
include file with a local scope quite safe. However, it's also possible that 
they may elect to do things a little differently, for example by adding 
their own stuff into your include file or by copying and pasting parts of 
your file into their own scene file. In these circumstances there is 
potential for the names you use in your local definitions to conflict with 
their own global declarations. I would therefore say that it is preferable 
to use the unique prefix everywhere as it makes it that little bit more 
robust in a wider range of circumstances.

Regards,
Chris B.


Post a reply to this message

From: SharkD
Subject: Re: Compliance: local variable scope
Date: 8 Jul 2008 22:35:01
Message: <web.487423b4f1a99dbbe2244ea70@news.povray.org>
"Chris B" <nom### [at] nomailcom> wrote:
> I would therefore say that it is preferable
> to use the unique prefix everywhere as it makes it that little bit more
> robust in a wider range of circumstances.

Thanks. I will labor to do so in my projects in the future.

-Mike


Post a reply to this message

From: Chris B
Subject: Local variable scope
Date: 31 Aug 2008 08:47:36
Message: <48ba92e8$1@news.povray.org>
"Chris B" <nom### [at] nomailcom> wrote in message 
news:4873f3cd$1@news.povray.org...
>
> "SharkD" <nomail@nomail> wrote in message 
> news:web.4873de0a2d11efca5d2e82c0@news.povray.org...
>> In order for an object to be compliant, can I simply change all the 
>> variables in
>> the include file to local scope? Or, must I also rename them all using 
>> the
>> object's abbreviation?
>>
> I would say that it is preferable to use the unique prefix everywhere as 
> it makes it that little bit more robust in a wider range of circumstances.
>

Ricky has documented a condition (over on povray.general) that means we'll 
need to actually make this a requirement for contributions to the Object 
Collection. He's pointed out that if the person is already using a 
particular Macro name in their scene files or include files (Macro names are 
always global in scope) and uses an object from the collection containing a 
local variable with the same name, then they will get errors when they try 
to render it.

For future contributions to the Object Collection can everyone please 
therefore prefix all variable names (even for local variables) with the 
unique prefix by which their contribution is known (same as with global 
declarations). Over time we'll need to go through and retro-fit that into 
existing contributions.

Regards,
Chris B.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.