[asterisk-users] Originate with label?

[Mark Murawski]

On 8/30/22 12:34, Antony Stone wrote:
> I want.
>>> However writing:
>>> 	Tracker=${CDR(uniqueid)};
>>>
>>> results in:
>>> 	MSet(Tracker=-1661872057.2349)
>>>
>>> systemname is missing.
>> Hi Antony,
>>
>> This is not a problem with MSet.
> No, it is indeed the documented behaviour of MSet "MSet behaves in a similar
> fashion to the way Set worked in 1.2/1.4 and is thus prone to doing things
> that you may not expect."


Please re-evaluate what I wrote previously.  Again, this is not a 
problem with MSet.  You can see this for yourself if you do an inline 
MSet(Tracker=${CDR(uniqueid)});  this will work fine.

Just because the documentation says that MSet should not be used, it's 
not appropriate to blame all undesirable behaviors on MSet(), since 
clearly MSet() is not the problem here.

You agreed below that $[] is not what you expected var=val to do... 
but... despite being unexpected, it's actually the defined behavior.  
And since there is no official specification for AEL, the specification 
for AEL is what AEL does.  (And I'm not trying to give you a hard time 
on this.. I'm just stating facts:  This is very much like Perl 
language.. where the spec for Perl *is* the Perl interpreter).

In this case, what the language does... is what it's supposed to do 
(unless it's a bug).  Ie: any inherent behaviors especially major 
transpiling behaviors, are going to stay the way they are as to not 
break people's existing usages of it.  I didn't write the AEL system, 
I'm just maintaining it.  So I'm not trying to "defend my honor" or 
anything.  I'm just stating the reality of the situation about 
maintaining compatibility and not making a major change to the language 
for syntactic sugar sake.

If you still need clarification as to why MSet isn't the problem, then 
this example should clear it up:

extensions.conf
MSet(Tracker=${CDR(uniqueid)});       // works as expected
MSet(Tracker=$[${CDR(uniqueid)}]);   // undesirable, due to conversion 
to math/boolean

extensions.ael
MSet(Tracker=${CDR(uniqueid)});        // works as expected
MSet(Tracker=$[${CDR(uniqueid)}]);    // undesirable, due to conversion 
to math/boolean

extensions.ael
Tracker=${CDR(uniqueid)};  // converted to 
MSet(Tracker=$[${CDR(uniqueid)}]);   which is the same *exact* behavior 
of extensions.conf


So... you can see from the above..  if you put your assignment value 
containing a string into a $[]  you'll loose the string value, 
regardless of whether or not it's an AEL var=val assignment or not.





> I think we'll have to disagree on what a programmer "expects" a syntax like
> var=value to do, then.
>
>> The fix/workaround is to explicitly use Set() when you need to work with
>> anything non-numeric and non-boolean
> True, and that is precisely what I have been doing in order to avoid such
> problems.  This example slipped through my conversion process (I've been
> converting previously-non-AEL dialplans into AEL because I prefer the general
> style).
>
> What I am suggesting is that Tracker=${CDR(uniqueid)} should be converted by
> AEL into Set(Tracker=${CDR(uniqueid)}) in order to avoid this sort of
> surprise.

On the flip-side... anyone who currently relies on purely 
numeric/boolean handling of the current implementation would be 
incredibly surprised to find their AEL suddenly broken... so we need to 
take that into account.


>
> If someone knows they want to perform arithmetic, they can write
> Result=$[${var1}-4] and end up with Set(Result=$[${var1}-4]) after AEL has
> done its transpilation.

When I write AEL needing arithmatic, i use var=val notation, skipping 
the need for Set and $[]
> I still intend to abide by the documentation for MSet "Avoid its use if
> possible.", and I simply think it would be good if AEL: did the same.
>
>

I'm a huge fan of enhancements and improvements and bug fixes, but as 
noted, MSet isn't the problem here.  I'll look into making an option 
available on switching the 'setter', but making the change from MSet to 
Set will not fix your issue.  But... currently I don't see a justifiable 
reason to make this a thing, unless there's actual problems demonstrated 
with the fact that MSet is being used.