[Home]

Summary:ASTERISK-10360: Impossible to make optional macro arguments in 1.4
Reporter:Luke-Jr (luke-jr)Labels:
Date Opened:2007-09-21 04:49:09Date Closed:2007-11-01 12:37:19
Priority:MajorRegression?No
Status:Closed/CompleteComponents:PBX/pbx_ael
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:In 1.2, AEL didn't validate macro argument counts, and all was well. Now AEL errors if they don't have the same number, which means macros are forced to have a fixed number of arguments ?
Comments:By: Steve Murphy (murf) 2007-10-03 13:09:17

Yes, sorry; but the emphasis on AEL2 was safety. And one common error in all procedural languages is mucking up the arglists in function calls.

since everything is strings in AEL, I can't really do any argument type checking, but at least we can help make sure the arg count is correct.

Things on my list for the future are stuff like letting macros return a value, and maybe we can slide in some default values for macro args... if you really feel strongly about this sort of thing, you might open a new bug report and ask for the feature as an enhancement request. I'll then be able to schedule it to some degree.
By: Luke-Jr (luke-jr) 2007-10-03 17:56:16

This isn't a feature request. It is a regression.
AEL2 is checking something that should not be checked and breaking backward compatbility.
By: Steve Murphy (murf) 2007-10-05 15:37:25

Well, ......

OK. I've thought it over and mayhaps we can compromise.
What if I reduced a macro arg count mismatch to a warning?

My main concern is that you are/have been hurting yourself by doing this sort of thing...

First of all, both macro and gosub, when called with fewer args than they use, will blithely use those unsupplied args... which could be blank, or... whatever might last have been passed under ARGn in some recursive call! (because the names ARG1, ARG2, etc are kept in global space in 1.2, and 1.4, and trunk for that matter.

So, the challenge: to insure enough commas/vertbars are in the call to pass empty values.

So, tell me: how did you insure that you weren't getting garbage in the calls with fewer args than used in the macro?
By: Steve Murphy (murf) 2007-10-05 15:44:39

Jsmith just sent me this pastebin:
( I am constantly in awe of his wickedly composed examples!!)


     [lab]
     exten => 211,1,Macro(argtest,one,two,three,four,five)
     exten => 211,n,Macro(argtest,1,2,3,4)
     
     [macro-argtest]
     exten => s,1,NoOp(${ARG1}:${ARG2}:${ARG3}:${ARG4}:${ARG5}:${ARG6})
     exten => s,n,Macro(argtest2,a,b,c)
     
     [macro-argtest2]
     exten => s,1,NoOp(${ARG1}:${ARG2}:${ARG3}:${ARG4}:${ARG5}:${ARG6})

     
     hockey*CLI> dial 211@lab
         -- Executing [211@lab:1] Macro("ALSA/default", "argtest|one|two|three|four|five") in new stack
         -- Executing [s@macro-argtest:1] NoOp("ALSA/default", "one:two:three:four:five:") in new stack
         -- Executing [s@macro-argtest:2] Macro("ALSA/default", "argtest2|a|b|c") in new stack
         -- Executing [s@macro-argtest2:1] NoOp("ALSA/default", "a:b:c:four:five:") in new stack
         -- Executing [211@lab:2] Macro("ALSA/default", "argtest|1|2|3|4") in new stack
         -- Executing [s@macro-argtest:1] NoOp("ALSA/default", "1:2:3:4::") in new stack
         -- Executing [s@macro-argtest:2] Macro("ALSA/default", "argtest2|a|b|c") in new stack
         -- Executing [s@macro-argtest2:1] NoOp("ALSA/default", "a:b:c:4::") in new stack
       == Auto fallthrough, channel 'ALSA/default' status is 'UNKNOWN'
      << Hangup on console >>
By: Luke-Jr (luke-jr) 2007-10-05 21:59:50

Hmm, interesting point! Perhaps coincidence I wasn't getting crazy output. On the other hand, if I had known this earlier, I could have saved myself a lot of coding, as many of my macros call other macros with the same exact arguments they received.
That is (simplified):

 macro foo(a, b, c, d) {
   &foo2(${a},${b},${c},${d});
 };

If you're going to make it balance macro arguments with extra commas, could you add some way to prevent that? Perhaps so I could replace such occurances with:

 macro foo(a, b, c, d) {
   &foo2(${a},@);
 };

(in case the 'a' variable had changed within 'foo')

I wouldn't mind having to put the variable name in brackets to signify that they are optional.
By: Steve Murphy (murf) 2007-11-01 12:37:18

Sorry, I've been thinking about for a while, and I'm going to close it. But, on the other hand, I'm open to this as an enhancement request against trunk. So, while I will close this bug, feel free to file another bug and request optional arguments for macros.

Here are some facts/reasons around these issues:

1. This has definitely turned into an enhancement request, and it's against 1.4, which will not allow enhancements.
2. Anything we do here with macro args will reflect back on Gosub in trunk, so the two have to be coordinated.
3. The names we use as arguments in trunk, are local variable names. They will disappear when the macro (gosub) returns. They will not be visible to macro invocations from the macro.
4. I prefer NOT to use tricks in underlying app calls, because from release to release, 'tricks' often end up being labeled as 'bugs' and getting fixed. And that then breaks the cool feature that people grew to depend on.
5. There are certain issues that must be worked out with "optional" args,  for a practical implementation. For instance, if an arg is not included, what value will it take in the called macro? Perhaps if we think about 'default args' instead of 'optional args', it might bear more fruit.