<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 8/31/22 05:29, Antony Stone wrote:<br>
</div>
<blockquote type="cite"
cite="mid:202208311129.23670.Antony.Stone@asterisk.open.source.it"><br>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Indeed.
I realise that the better solution might be to wrap assignments (inside Set()
or MSet(), no matter) with $[..] *only* if the expressions contain arithmetic
operators + - * / and not if they are simple a=b assignments, including
a=${b}.
This would ensure that even if ${b} expanded to something containing a dash,
it would be interpreted as a mathematical minus sign in a=${b}
</pre>
</blockquote>
<br>
<br>
I would hesitate about making this happen as well.. without a
migration-plan in place.<br>
<br>
Typically:<br>
1) Add a new option that would flip the behavior of var=val sets to
auto-detect math and act accordingly on whether or not to use $[]
(which comes with its own issues)<br>
<br>
2) Warn about the change in the application: Ie: In Asterisk 20
there would be a warning stating in Asterisk 21 this will be the new
default behavior<br>
<br>
<br>
But, there's issues with auto-detecting math. Because it's
impossible for a compiler/transpiler to correctly assess *intent*.
It can read the symbols and say, "Oh, I see you have some math
symbols here, lets force this to math mode" in a purely search and
replace context. Here's the problem with that. Variables can
contain all kinds of (very unpredictable from a compiler
perspective) stuff.<br>
<br>
How is the compiler supposed to tell the difference between the
following examples, for intent<br>
var1 = ${a} + ${b} / ${c};<br>
var2 = Hello World / Hello Bob / Hello Sue<br>
var3 = *1*1*1* HEY THERE IS A PROBLEM *1*1*1<br>
var4 = This-Is-Some-Dash-Separated-Data: 1-2-3-4-5-6<br>
<br>
I'm not saying I personally write code like this, but there are some
quick examples that can easily proof this to be the wrong approach<br>
<br>
I think what you're looking for is quoted strings. <br>
var1 = "This-Is-Some-Dash-Separated-Data: 1-2-3-4-5-6"<br>
Which gets converted to an MSet(var1=$[
"This-Is-Some-Dash-Separated-Data: 1-2-3-4-5-6" ])<br>
<br>
Which considering MSet actually has a desired behavior here of
removing quotes, your value of var1 will be exactly what you expect
it to be<br>
<br>
<br>
AEL<br>
<br>
<pre> 9999 => {</pre>
<pre> var = "hi there - what's - up 0 * 1 / 4 not math";</pre>
<pre> NoOp(${var});</pre>
<pre> }</pre>
<br>
Dialplan:<br>
<br>
<pre>vbox-markm-x64*CLI> dialplan show 9999@services</pre>
<pre>[ Context 'services' created by 'pbx_ael' ]</pre>
<pre> '9999' => 1. MSet(var=$[ "hi there - what's - up 0 * 1 / 4 not math"]) [pbx_ael]</pre>
<pre> 2. NoOp(${var}) [pbx_ael]</pre>
<br>
<br>
Execution:<br>
<br>
<pre>MSet(var="hi there - what's - up 0 * 1 / 4 not math")</pre>
<pre>NoOp(hi there - what's - up 0 * 1 / 4 not math)</pre>
<br>
<br>
</body>
</html>