hi,

"yesbird" <nomail@nomail> wrote:
> Thanks a lot, it really works ! (on ver. 3.8 only),

ah, yes, forgot, sorry.  'optional' was new in 3.8.


> > (have a look at the 'queues.inc' for use of optional args)
>
> but I can't find this file anywhere, where did you get from ?

my own, on the wiki.  however, there's also a macro in 'pvars.inc' (on wiki)
which has only optional arguments.


regards, jr.

Post a reply to this message

> my own, on the wiki.  however, there's also a macro in 'pvars.inc' (on wiki)
> which has only optional arguments.

Thanks, I've found it, moreover structures are very useful itself :)
--
YB

Post a reply to this message

"yesbird" <nomail@nomail> wrote:
> Hi, guys !
>
> Is there a way to assign an empty value to variable, using something like 'None'
> in Python or NULL in C ? I would like to use it while passing parameters to
> macros, for more compact notation.
> Can not find any info in docs about it.
>
> Thanks in advance,
> --
> YB

As jr pointed out, there are work-arounds.
I find the optional keyword, and its required commas to be awkward and clunky.

Can you store your macro parameters in an array?
Then the array will exist, but it might not have certain elements defined.  Then
you test each element in the size of the array
#declare SizeOfArray = dimension_size (Array, 1)-1;
#for (i, 0, SizeOfArray)
     #if (!defined (Array[i])
     .....
#end

Just another option.

Post a reply to this message

Hi,
> Just another option.

Good idea, but 'optional' works fine for me, as I prefer to simplify the passing
process.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
Hi,
> my own, on the wiki.  however, there's also a macro in 'pvars.inc' (on wiki)
> which has only optional arguments.

Looks like there is some limitation on number of optional args:
----------------------------------------------
#macro _vector(optional p1, optional p2, optional p3)
#end

_vector(1, 2, 3) // OK
_vector(1, 2,  ) // OK
_vector(1,     ) // Error
----------------------------------------------

I wonder how is your code works ?

Regards,
--
YB

Post a reply to this message

Sorry, solution was:
-------------------
_vector(1,,    ) // OK
-------------------
Number of commas is matter

--
YB

Post a reply to this message

"yesbird" <nomail@nomail> wrote:
> Sorry, solution was:
> -------------------
> _vector(1,,    ) // OK
> -------------------
> Number of commas is matter
>
> --
> YB

Yes, and that's why I find that method awkward.

There's also no way to write a macro with a variable number of arguments - it
has to be fixed.

But now that we have dynamic arrays, and indeed, mixed arrays, I think I'd opt
for passing an array of arguments in, and then having the macro analyze and
process the array.

We still don't have any means of checking what the data type is without aborting
the parsing phase with an error, so just be aware of that as well.

- BE

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "yesbird" <nomail@nomail> wrote:
> > Sorry, solution was:
> > -------------------
> > _vector(1,,    ) // OK
> > -------------------
> > Number of commas is matter
> > YB

yes, optional value(s), not position(s).


> Yes, and that's why I find that method awkward.

for YB's benefit, I think that may be just because the parser is so .. lenient
elsewhere.  as you know, much POV-Ray code published here "skimps" on detail,
the ';' terminator is rarely used (or "taken serious" even, I feel), meshes and
such often omit the commas between neighbouring vector values etc.  in fact,
'box {your ears}' would have sufficed ;-).  with the macro it's simply that
w/out the commas, the parser would have no (literal) clue which of the args were
omitted.


> There's also no way to write a macro with a variable number of arguments - it
> has to be fixed.
> But now that we have dynamic arrays, and indeed, mixed arrays, I think I'd opt
> for passing an array of arguments in, and then having the macro analyze and
> process the array.

yes.  (dictionaries, too)


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> for YB's benefit, I think that may be just because the parser is so .. lenient
> elsewhere.  as you know, much POV-Ray code published here "skimps" on detail,
> the ';' terminator is rarely used (or "taken serious" even, I feel), meshes and
> such often omit the commas between neighbouring vector values etc.

This is true, and we have some benefits and some hardships because of that.
We have lazy programming practices, black-box variable types and unknown
castings, parser "surprises", and bits of mystery code and loose ends all over
the internals.

>  in fact,
> 'box {your ears}' would have sufficed ;-).


Oh, hardly.  There are days where you are simply unruly to the point where we
don't even know where to start figuring out what to do with you.   :P

  with the macro it's simply that
> w/out the commas, the parser would have no (literal) clue which of the args were
> omitted.

Indeed.  No idea how such things are typically handled in other languages.


> > There's also no way to write a macro with a variable number of arguments - it
> > has to be fixed.
> > But now that we have dynamic arrays, and indeed, mixed arrays, I think I'd opt
> > for passing an array of arguments in, and then having the macro analyze and
> > process the array.

> yes.  (dictionaries, too)

See?   Positively flabbergasting.   An in public, no less.
You and your Dark Magic.

../jrEvilSpells.sh >/dev/null 2>&1

Post a reply to this message

Hi,
> yes.  (dictionaries, too)

Thanks, they much more convenient to me.
--
YB

Post a reply to this message