On Tuesday 30 August 2022 at 23:51:34, Mark Murawski wrote:> On 8/30/22 12:34, Antony Stone wrote:> >>> Tracker=${CDR(uniqueid)}; > >>> > >>> results in: > >>> MSet(Tracker=-1661872057.2349) > >>> > >>> systemname is missing. > > 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.Aha - now I see that my problems (or confusions) are being caused by the automatic wrapping in $[..] and not by MSet itself, thank you.> 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.Agreed.> > I think we'll have to disagree on what a programmer "expects" a syntax > > like var=value to do, then.> > 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.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}> I'm a huge fan of enhancements and improvements and bug fixes, but as > noted, MSet isn't the problem here.Indeed, I agree with you now. I was focusing on MSet and not $[..]> 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.I would still be interested to know whether there are any examples of MSet() doing what one expects and Set() in the same situation causing a problem. Thanks, Antony. -- This sentence contains exacly three erors. Please reply to the list; please *don't* CC me.
On 8/31/2022 5:29 AM, Antony Stone wrote:> On Tuesday 30 August 2022 at 23:51:34, Mark Murawski wrote: > >> 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. > I would still be interested to know whether there are any examples of MSet() > doing what one expects and Set() in the same situation causing a problem.One thing MSet does that Set doesn't is assign multiple variables at once (hence the name, multiple set). e.g. instead of: same => n,Set(a=1) same => n,Set(b=2) same => n,Set(c=3) just do: same => n,MSet(a=1,b=2,c=3) I'm not sure if that still works in AEL, e.g. if you can do: a = 1, b = 2, c = 3; This requires MSet; the Set application only sets one variable per invocation. The SET function has limited ability to do this but doesn't always work. This is not so much "causing a problem" as a limitation of Set that is really by design. This is probably a big reason MSet is not and won't be deprecated - it serves this distinctly different purpose. Judicious use of MSet can reduce dialplan clutter when setting lots of variables, but typically different assignments are not written like that anyways, so maybe not relevant to AEL.
On 8/31/22 05:29, Antony Stone wrote:> >>> 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. > 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} >I would hesitate about making this happen as well.. without a migration-plan in place. Typically: 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) 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 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. How is the compiler supposed to tell the difference between the following examples, for intent var1 = ${a} + ${b} / ${c}; var2 = Hello World / Hello Bob / Hello Sue var3 = *1*1*1* HEY THERE IS A PROBLEM *1*1*1 var4 = This-Is-Some-Dash-Separated-Data: 1-2-3-4-5-6 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 I think what you're looking for is quoted strings. var1 = "This-Is-Some-Dash-Separated-Data: 1-2-3-4-5-6" Which gets converted to an MSet(var1=$[ "This-Is-Some-Dash-Separated-Data: 1-2-3-4-5-6" ]) 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 AEL 9999 => { var = "hi there - what's - up 0 * 1 / 4 not math"; NoOp(${var}); } Dialplan: vbox-markm-x64*CLI> dialplan show 9999 at services [ Context 'services' created by 'pbx_ael' ] '9999' => 1. MSet(var=$[ "hi there - what's - up 0 * 1 / 4 not math"]) [pbx_ael] 2. NoOp(${var}) [pbx_ael] Execution: MSet(var="hi there - what's - up 0 * 1 / 4 not math") NoOp(hi there - what's - up 0 * 1 / 4 not math) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20220831/494a7993/attachment.html>