POV-Ray : Newsgroups : povray.general : Let me get this straight--a local variable can't have the same name as a ma= : Re: Let me get this straight--a local variable can't have the same name as = Server Time
30 Jul 2024 18:13:35 EDT (-0400)
  Re: Let me get this straight--a local variable can't have the same name as =  
From: Cousin Ricky
Date: 31 Aug 2008 13:35:01
Message: <web.48bad4da874903f685de7b680@news.povray.org>
"Reactor" <rea### [at] hotmailcom> wrote:
>
> While it can be a hassle, the documentation states that all macros are permanent
> and global in scope.

That shouldn't make a difference.  A local variable should override any and all
global identifiers within its scope.  That is the very purpose of local
variables: so different parts of a program need not be concerned about how the
other parts do their jobs.  I maintain that having to avoid name collisions
with the internal workings of external subprograms is totally unreasonable.
It's the cyber-equivalent of having your lawn mower fail because it uses the
same type of motor oil as your wife's car.

> If the variable A had shared a name with a #declared
> variable, the local one would have behaved as expected (but there would be no
> way to reference the global of the same name while the local identifier
> exists).

I should state that the main file and the include file were written by 2
different people--let's call them "Rick" and "Sam."

If Sam needed a global A from within a macro, then he (obviously) wouldn't
declare a local A.  But if he's writing a stand-alone include file, then how is
he supposed to know that Rick will declare a macro A?  And how is Rick supposed
to know that Sam has a local variable A in one of his (supposedly) black boxes?

>  As for the last part, of redefining an identifier as a different
> type, Povray already permits that except for macros, because they are
> permanent.  To do it for a macro, you must use the #undef directive.

Again, the permanence of macros (and functions) is not the issue.  When a local
identifier's scope is destroyed, the global identifier becomes accessible
again.

A macro parameter can have the same name as a macro.  If I name the macro Atom
instead of A, the scene runs fine.  Is a macro name less "global" or less
"permanent" in this case?

> Scope control is something I briefly wrote about for a tentative list of changes
> for SDL in 4.0.  There is (as always) more than one way to address this.  What
> would you recommend?  On my list I put down the introduction of namespaces and
> some new directives for scope control:
>
> <snip>
> I wouldn't mind seeing new directives, such as #global for global variables
> (instead of declare) and #const for properties that can be referenced but not
> set (i.e. using #const with your camera{} block would allow macros to retrieve
> the camera settings, but not change them).  #local should be truly local to its
> block, and not freely accessible within a file unless it is defined outside of
> other code.
>
> #private might also be useful from properties that you want to keep hidden from
> outside of the object, and maybe a #static storage class for some variables or
> for preventing macros internal to another macro from being called externally.
> </snip>

These are all good ideas.  But I would prioritize eliminating collisions between
local and global identifiers--something that should never be in the first place.

After that, I would like to see persistent local variables in include files
(#static).  (I wound not prioritize #static variables within macros.)

Then it would be nice to have local or private macros.


Post a reply to this message

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