In article <402d4192@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> It is absolutely necessary.  What you expect is functions to have a scope on
> the same level as macros do.  This is not the case, and you don't want it to
> be the case either (it is possible to construct cases where, if this would
> be the case, it would badly break functions - i.e. when generating a
> function with macros).

Would it necessarily do so? I don't see how it could be a problem for a 
parameter name to hide a parse-time variable name. The person writing 
the function could change the parameter name if the variable is needed, 
otherwise it just avoids situations like this one.


> The solution is that the include files should not use generic names for
> function variable names.  A good solution would be to use all lower case
> variable names with a prefix, i.e. "math__a" (note the *two* underscore
> chars, this makes sure this will never be a keyword) instead of "A" in
> math.inc .  This would work because the documentation already suggests to
> the user to never use all lower case names.

Shorter: end the name with an underscore: a_
A keyword won't end with an underscore, and variable names typically 
don't either, aside from it being recommended to use upper case letters 
in them. I don't see a reason for the parameters to conflict with 
parse-time variables, though.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message