[SR-Dev] new operators & if($v) behaviour

[Daniel-Constantin Mierla]

Hello,

On 04/24/2009 06:36 PM, Henning Westerholt wrote:
> On Friday 24 April 2009, Andrei Pelinescu-Onciul wrote:
>   
>> 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(@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.
>   
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/