24 Apr
2009
24 Apr
'09
7:46 p.m.
Hello,
On 04/24/2009 06:36 PM, Henning Westerholt wrote:
On Friday 24 April 2009, Andrei Pelinescu-Onciul
wrote:
we had a lot of discussions in the past about the ambiguity of
conditions, expecially regarding the PV expressions. I am for explicity
operators:
if(defined($hdr(X-Foobar)) ...
then I know that is defined.
if($xyz=="") ...
then I know it is empty string... a.s.o.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
Right now we have a problem with old scripts that
use things like
if ($v) (where $v could be avp, pseudovar or select).
$v can evaluate to a int, a string or undefined.
Now for string and undefined the if will evaluate to false (string
being an error) and an error will be logged.
If the type of $v can be found prior to runtime (e.g. @select is always
string) you'll even get a parse error.
I plan to add some new operators, to properly deal with these cases:
defined($v)
strempty($v)
strlen($v)
but the question still remains if we should preserve compatibility and
still support things like if (@to.tag), instead of if (!strempty((a)to.tag))
or if (@to.tag!="").
Hi Andrei,
does this also apply to kamailio pseudo-variables that evaluates to a string,
like this:
if ($hdr(X-Foobar)) { # do something on this hdr }
If yes, then i'd vote for keeping this functionality, as its more easier to
read and understand as using another operator, as Miklos already said.