|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in
news:3cd3a6f6@news.povray.org:
> It isn't a new limitation in 3.5 also you seem to give that impression.
Try this on 3.1:
#macro Center(Obj)
object {Obj}
#end
#include "shapes.inc"
#declare X = sphere {0,1}
Center (X)
It won't choke. Now try it on 3.5. Now try to find anything in the
documentation that says this code is no longer valid under 3.5.
(Yes, I know /why/ it won't choke 3.1... The reason why it won't choke 3.1
is irrelevant; the fact that it *does* choke 3.5 is the problem.)
> Having the same name twice in the same namespace simply cannot work.
Please tell that to the RC3 binary. It copes just fine with #declared/
#localed names that match macro parameters:
#local X = function(x,y,z) {x+y+z}
#macro A(X) #end
Given that there's no valid reason to use the output of a macro to
determine the name of another macro's parameters, not performing macro
expansion during this portion of parsing seems reasonable for consistancy's
sake alone. For instance, why should the code above work when #macro X()
#end #macro A(X) #end doesn't?
> the documentation explains the namespace rules.
In this specific case, telling the user that he/she can't do #macro A()
#macro B(A, D) is rather pointless when the user doesn't know that #macro B
(A, D) exists in the first place. The point is that the standard includes
are consuming huge swaths of the namespace without any real documentation
or regard for what they might be stepping all over. Finding safe names was
not a matter of luck with 3.1; it is very much a matter of luck with 3.5 as
soon as one #includes anything. I don't think this change is particularly
rational or user friendly.
Again, if the parser cannot practically be fixed at this stage, could the
standard includes at least be modified so their macro parameter names are
all lower case (like all other Pov keywords), mangled to reduce the chances
of collisions with user macros, or added to the reserved keywords list in
docs section 6.1.1?
Post a reply to this message
|
|