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.
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
