POV-Ray : Newsgroups : povray.programming : Overloading identifiers : Re: Overloading identifiers Server Time
29 Jul 2024 00:37:56 EDT (-0400)
  Re: Overloading identifiers  
From: Ron Parker
Date: 28 Jan 1999 13:05:27
Message: <36b0a6e7.0@news.povray.org>
On 28 Jan 1999 12:19:49 -0500, Nieminen Mika <war### [at] cctutfi> wrote:
>Ron Parker <par### [at] my-dejanewscom> wrote:
>  In this case povray could issue an error message like "Ambiguous operands".
>  Then perhaps you can typecast the operands like this:

I can see this being confusing if one third-party .inc file does

#declare tmp=<2,3,4>;

and another third-party .inc file does

#declare tmp=5;
sphere {tmp, 2 texture {blah}};

So is this ambiguous, which would be confusing, or does it use the
<2,3,4> definition of tmp, which would just be wrong? Granted, they 
should have used #local, but you can't count on that.  Except for 
floats and vectors, though, I guess I don't see any technical problems
with the idea.  I'm just not sure it's strictly necessary and it seems
like it would just add to the confusion newbies already experience.

>  Even if overloadable identifiers were not good, overloadable macros should
>be very handy.

This I tend to agree with, but you can still accomplish the same thing by
using a good naming scheme.  Also, I'm thinking you would have to have
a different number of arguments to each version of the macro, as there's 
no other way to tell them apart.  The most likely usage of this kind of
macro overloading seems like it would be to default parameters, and it 
seems like that would be better accomplished by directly allowing default 
parameters.  (For example, I wish my TorusSpline macro could have the 
third parameter be optional.)  This wouldn't even require any syntax 
changes, just a parser change: if it finds a ')' when it expected to find 
a comma or another parameter, it should just set the rest of the formal 
parameters to undefined and call the macro rather than generating an 
error as it does now.  This will also require a tokenizer change to stop 
the search through the stack of definitions when an identifier is marked 
as "temporarily undefined" at some level, to prevent hard-to-find problems 
with code like this, which I would expect to generate a sphere of radius 1 
centered on <2,2,2>:

#macro baz(foo, bar)
  #ifndef (bar)
    #declare bar=1;
  #end
  sphere {foo,bar}
#end

#declare bar=5;

baz(2);


Post a reply to this message

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