 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ron Parker" wrote:
> Even if it did find the Parent's "Var" when it tried to
> figure out what "Var + 1" means, it would still put the
> result in a local variable called Var which would be
> thrown out when Child() returned, leaving Parent()'s
> version set to what it was.
As I would expect.
> Any other behavior would make #local meaningless.
Agreed.
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 28)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a9edf2f@news.povray.org>, "Rune" <run### [at] iname com>
wrote:
> > 4.) When ASSIGNING A VALUE TO AN EXISTING identifier using #declare,
> > it assigns it to the most recent, most local version at the time.
>
> I didn't know that! That's great! It solves my problems! Thanks!
This does not seem right...#declare should always create a global
variable. It is certainly unintuitive...to me at least.
I have suggested something before that would solve this, and it's
partially implemented in a patch (and included in the most recent
version of MegaPOV): the #set directive, which will assign to the most
local version of a variable, but will not create a new identifier. You
would use #declare and #local to *create* global and local variables,
and #set to modify them.
This seems like a cleaner and less confusing system...
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 02 Mar 2001 07:54:16 -0500, Chris Huff wrote:
>In article <3a9edf2f@news.povray.org>, "Rune" <run### [at] inamecom>
>wrote:
>
>> > 4.) When ASSIGNING A VALUE TO AN EXISTING identifier using #declare,
>> > it assigns it to the most recent, most local version at the time.
>>
>> I didn't know that! That's great! It solves my problems! Thanks!
>
>This does not seem right...#declare should always create a global
>variable. It is certainly unintuitive...to me at least.
#declare always CREATES a global variable, but it doesn't always MODIFY one.
That's the way it's always been, and it's documented behavior. It seems
intuitive to me: if you use #declare to modify a variable, you're guaranteed
to modify the variable that you would have seen when you interrogated it.
Wouldn't it suck to do it otherwise if you had something like this?
#macro ForceVarInBounds()
#ifdef(Var)
#if (Var < 0) #declare Var=0; #end
#if (Var > 255) #declare Var=255; #end
#end // ifdef
#end // macro
#macro DoStuff() {
#local Var=SomeFunction();
ForceVarInBounds()
DoSomethingCriticalWithVar()
#end // macro
Oops... The ForceVarInBounds macro didn't do what you thought it would.
Yeah, I know, we shouldn't use global variables. That being the case,
this will never be a problem.
>This seems like a cleaner and less confusing system...
It doesn't seem less confusing to me. If you implement it, I forsee lots of
#ifdef (foo)
#set foo = SomeComplicatedMacro();
#else
#declare foo = SomeComplicatedMacro();
#end
>
>--
>Christopher James Huff
>Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
>TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
>
><><
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ron Parker" wrote:
> It seems intuitive to me: if you use #declare to modify a variable,
> you're guaranteed to modify the variable that you would have seen
> when you interrogated it.
> Wouldn't it suck to do it otherwise if you had something like this?
>
> #macro ForceVarInBounds()
> #ifdef(Var)
> #if (Var < 0) #declare Var=0; #end
> #if (Var > 255) #declare Var=255; #end
> #end // ifdef
> #end // macro
>
> #macro DoStuff() {
> #local Var=SomeFunction();
> ForceVarInBounds()
> DoSomethingCriticalWithVar()
> #end // macro
Exactly!
That's basically what I needed to do, and I was very pleased to find out
that it could be done in an easy manner. I personally find it intuitive too.
> That's the way it's always been, and it's documented behavior.
I see now that the rules you stated are taken right out of the documentation
in the section "Identifier name collisions". I should reread the whole
documentation once in a while...
I did found a bug though. In the documentation this is stated:
> Suppose inside myinc.inc you do...
>
> #local D = 789;
>
> If you are inside myinc.inc and you want to increment D by
> one, you might try to do...
>
> #local D = D + 1;
>
> but if you try to do that inside MyMacro you'll create a new
> D which is local to MyMacro and not the D which is external
> to MyMacro but local to myinc.inc.
POV-Ray does not work as the documentation states. It works like this:
> (...)
> but if you try to do that inside MyMacro you'll get the error
> message "Cannot assign uninitialized identifier".
Whether this is a bug in POV-Ray or in the documentation I will let others
decide.
I personally think that POV-Ray should keep its current functionality since
it prevents the user from making stupid mistakes based on misconceptions,
such as the example in the documentation.
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 28)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 2 Mar 2001 15:40:17 +0100, Rune wrote:
>POV-Ray does not work as the documentation states. It works like this:
>
>> (...)
>> but if you try to do that inside MyMacro you'll get the error
>> message "Cannot assign uninitialized identifier".
Right. That's the comment I put in square brackets:
[actually, as you noticed, this is an error.]
>Whether this is a bug in POV-Ray or in the documentation I will let others
>decide.
I think it's probably easier to fix in the documentation than in the
implementation. :) In any case, I'm not sure I like the idea of allowing
it to happen without at least pointing it out to the user. And, as you
also noted, it's easy enough to get around:
#local temp1 = D+1;
#local D = temp1;
#undef temp1
I suggest we leave it as it is to avoid confusion, but note it in the docs.
And hope that next time it comes up someone actually reads the docs. :)
>I personally think that POV-Ray should keep its current functionality since
>it prevents the user from making stupid mistakes based on misconceptions,
>such as the example in the documentation.
Ah, then we agree.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <slr### [at] fwicom>, ron### [at] povrayorg
wrote:
Well, that macro would have been written as this, when using my idea:
#macro ForceVarInBounds()
#ifdef(Var)
#if (Var < 0) #set Var=0; #end
#if (Var > 255) #set Var=255; #end
#end // ifdef
#end // macro
Or even better:
#macro ForceVarInBounds(Var, Min, Max)
#if (Var < Min) #set Var=Min; #end
#if (Var > Max) #set Var=Max; #end
#end // macro
I don't see the problem...
> #macro DoStuff() {
> #local Var=SomeFunction();
> ForceVarInBounds()
> DoSomethingCriticalWithVar()
> #end // macro
>
> Oops... The ForceVarInBounds macro didn't do what you thought it would.
I wouldn't write code like that, unless I wanted a global version of
"Var"...the #set versions would look for a global variable named "Var"
or take a specific variable and modify it, no matter what it's name is.
I still do not think a macro should be able to modify local variables
outside it unless they are passed in as a parameter or are simply at a
higher level (#local variables of the include file the macro is in, for
example. *Not* #local variables of macros that call the macro.). Of what
use is this behavior?
It just doesn't seem like a good idea for "#declare SomeVar = ..." to
behave differently depending on whether SomeVar already exists and
whether it is local.
> It doesn't seem less confusing to me. If you implement it, I forsee lots
> of
> #ifdef (foo)
> #set foo = SomeComplicatedMacro();
> #else
> #declare foo = SomeComplicatedMacro();
> #end
Why? That code would modify foo if it exists already, and otherwise
create a global variable named foo. What's confusing about that?
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 02 Mar 2001 16:29:36 -0500, Chris Huff wrote:
>I don't see the problem...
The problem is that #set just makes the syntax more complicated; see below.
>I wouldn't write code like that, unless I wanted a global version of
>"Var"...the #set versions would look for a global variable named "Var"
>or take a specific variable and modify it, no matter what it's name is.
FWIW, I wouldn't write code like that either, but in the context of an
include file it makes more sense.
>I still do not think a macro should be able to modify local variables
>outside it unless they are passed in as a parameter or are simply at a
>higher level (#local variables of the include file the macro is in, for
>example. *Not* #local variables of macros that call the macro.). Of what
>use is this behavior?
By the way, trying to modify local variables of the include file the macro
is in will not do what you think it will in all cases. The local variables
of that include file will go out of scope when it finishes parsing, which
is quite likely to be before the macro is invoked the first time.
In any case, include files and macros are the same thing internally.
Include files are just bigger, in general.
The behavior is most useful when you're writing an include file or a macro
that needs to call certain other macros (possibly ones you didn't write)
that change the values of global variables, and you don't want those changes
to affect anything the person who called your include file might have had
going on. Suppose you're planning on building something on top of Colefax's
spline include file, perhaps a roller coaster construction set. Suppose you
plan to make it available for public use. Further suppose that Colefax's
spline include file uses global variables, since I haven't checked that it
does. :) Now, what happens when someone uses your roller coaster construction
set to make a roller coaster, then uses Colefax's splines to make, say, the
string of a balloon? Do the globals get mixed together higgledy-piggledy?
To explain it more succinctly: the current behavior of #declare makes it
relatively transparent to turn .pov files into .inc files that can be used
from any .pov file, anytime, by making the "global" variable space not be
quite so global. It's not that different than namespaces, really.
If anything is a bug here, it's that macro invocations don't happen in the
context in which the macro was declared (called "closures" in CS-ese) but
that's a can of worms nobody really wants to open (from a programming
standpoint, that is - they'd be very useful from a scripting standpoint.)
>It just doesn't seem like a good idea for "#declare SomeVar = ..." to
>behave differently depending on whether SomeVar already exists and
>whether it is local.
Only on whether it already exists, not on whether it is local. At any rate,
it's not something we can argue about: it's documented that way, it was
deliberately written to work that way, and that way it will stay.
>> It doesn't seem less confusing to me. If you implement it, I forsee lots
>> of
>> #ifdef (foo)
>> #set foo = SomeComplicatedMacro();
>> #else
>> #declare foo = SomeComplicatedMacro();
>> #end
>
>Why? That code would modify foo if it exists already, and otherwise
>create a global variable named foo. What's confusing about that?
What's bad (not necessarily confusing) about that is that it'd have to crop
up in lots of code that used to work:
#declare foo=0;
#while (foo < 100)
#declare bar=Something(foo);
DoSomething(foo,bar);
#declare foo=foo+1;
#end
This would become a parse error in your version, because #declare would
find a defined identifier on the LHS the second time through the loop.
Making working scenes break is not generally considered A Good Thing.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <slr### [at] fwicom>, ron### [at] povrayorg
wrote:
> #declare foo=0;
> #while (foo < 100)
> #declare bar=Something(foo);
> DoSomething(foo,bar);
> #declare foo=foo+1;
> #end
>
> This would become a parse error in your version, because #declare would
> find a defined identifier on the LHS the second time through the loop.
> Making working scenes break is not generally considered A Good Thing.
It doesn't...the #set patch doesn't and won't interfere with #declare
being used to modify variables created with #declare. The variable "bar"
would be a global variable created by the first loop and modified by
later loops. You *could* do:
#ifndef(foo)
#declare foo = Something(foo);
#else
#set foo = Something();
#end
But this would act the same as simply:
#declare foo = Something(foo);
My objection is simply to #declare modifying variables created by #local.
Maybe a new #global keyword would be the best choice...
#global Foo = bar;
would create a global variable named Foo or modify an existing global
variable with that name, and
#local Foo = Foo + global(Foo);
would add a local Foo to the global Foo. (assigning the result to the
local version, of course)
#declare would act the way it does now...or at least the way it is
documented to act.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Huff" wrote:
> My objection is simply to #declare modifying variables created
> by #local.
What exactly is your objection based on? As it is now it will almost always
work as the user expects, without the user having to think too much about
it.
> Maybe a new #global keyword would be the best choice...
> #global Foo = bar;
> would create a global variable named Foo or modify an existing
> global variable with that name, and
> #local Foo = Foo + global(Foo);
> would add a local Foo to the global Foo. (assigning the result
> to the local version, of course)
When working with include files and macros created by other people, it is
very useful that using #local prevents these from interfering with each
other and with your own code if they by chance happens to use some of the
same variable names.
However, there is no point in intentionally to assign variables at different
levels with the same names. That was never the intention, if I have
understood correctly. Use different variable names instead.
For that reason it would not be logical to make features which would
specifically allow the user to working with several similarly named
variables at the same time. No need to make things more complicated than
necessary.
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 28)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 03 Mar 2001 13:00:38 -0500, Chris Huff wrote:
>#declare would act the way it does now...or at least the way it is
>documented to act.
It does act the way it is documented to act. Local doesn't act quite
the way it is documented to act, though.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
