Cousin Ricky <ric### [at] yahoocom> wrote:
> How widespread are you recommending this convention?
It might help obviate "reading the mind of every Povver" if some mechanism were
implemented to prepend/append some designation to the variables to make them
"unique" to any given include file.
BE23062020inc_var1 = pow(e, i*pi);
Verbose, more work, jr will have an apopleptic fit, but serves as a functional
I would love to be able to declare identifiers using some form of formula or
concatenation - though I don't know what that would involve in the source code.
If I wanted a01 through a10, then I could write a for loop that would declare
#for (N, 1, 10)
#declare Identifier ("a" + str(N)) = pow(N, 2);
(not proper syntax, but you get the _idea_)
And if THAT were possible, then at the top of the include file, one could
#declare INC_PREFIX = "BE23062020inc_";
write a small macro to prepend that to any identifier name, and then
#declare INC(a) = 0;
would be the/a way you'd handle all of the names in that file.
I know we have that parse thing (the name always escapes me) that writes to a
file and includes it back in...
> > Your post touches on other changes I've made in povr. You mentioned
> > math.inc defining - via our scene description language - functions
> > which look like fully inbuilt keywords/functions. We have also the all
> > lower case eval_pigment macro. I think these lower case names bad form
> > and I've changed them to have upper case characters in addition to
> > moving the functions from math.inc to functions.inc.
Why not make them ... fully inbuilt keywords/functions?
> The problem with renaming functions and macros is that it would break
> older scenes. But keeping the old names alongside the new names would
> solve that problem. Since these old names are already part of the
> POV-Ray canon, avoiding new keywords with these names should not be a
How much does it take to implement an alias system?
It would be ever so nice to be able to rename inbuilt keywords and functions.
> > Plus eval_pigment I
> > moved to math.inc, as Eval_Pigment, because it's a macro not a function.
> It seems to me that Eval_Pigment() belongs in textures.inc.
Move it into source code! :)
> > I want to get to where f_ prefixed functions indicate inbuilt functions.
> > The F_ prefixed functions indicate SDL defined functions shipped in povr
> > include files.
> > Something I've stumbled over is seeing odd(...) in a scene file and
> > thinking it's an SDL keyword - but then not seeing any documentation for
> > it. I might not always be getting today's math.inc odd() in any case. At
> > least if I see the F_ prefix I'll know it's something defined in an
> > include and I need to be careful.
odd, even, and those sorts of functions should be in source code.
I find it ridiculous to include a whole file simply for one little function.
Or have to hunt down the include file to copy/paste the code.
> What do you think of e and o in consts.inc? I think o would be better
> as O, because the Cartesian origin is normally denoted with a capital O.
> But Euler's constant is always lowercase e. Would it be worth making
> a keyword?
Post a reply to this message