new operators & if($v) behaviour
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!=""). What's trickier is that if we allow strings in int expressions then we have 2 problems: - "" evaluates to 1 or 0? - how to evaluate a string in an integer context: is "abc" 1 or 3 (strlen)? How about "123" ? - $v is 0 if v is not defined? Note that if we do this it will work in all types of expressions, e.g. if string evaluates to strlen(string) in interger context then: 3+"abc" = 6 ; 3+ ""=3 ; 3+"9"=4 3+"0"=4. Andrei
andrei, in my opinion we should only allow boolean result in condition expressions. so if someone want to test if a pv value is null, empty string, 0, undefined, etc., the test should be explicit, like using your functions
defined($v) strempty($v) strlen($v)
but i'm not sure if it is in all cases possible to tell apart if a pseudo variable is undefined or if its value is null or 0. at least in the pass this has caused lots of confusion and if we can get it now cleared, it would be great. -- juha
Hi Andrei, On 04/24/2009 11:47 AM, 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!="").
I vote fore keeping the support for "if (@to.tag)" like expressions, and adding the extra functions for more precise checks if necessary. So a string value could evaluate to true if it exists and not "". I think it is easier to read and understand "if (@to.tag)" then "if (!strempty(@to.tag))" I was already planning to add the above functions to SER about a year ago, and we had a discussion about this in the list, but we did not need these functions in the script so far. I think they would be needed only for example when there is a parameter in a header field without any value, and one would like to check the existence of the param.
What's trickier is that if we allow strings in int expressions then we have 2 problems:
- "" evaluates to 1 or 0?
"" meant 0, changing it to the opposite would be quite confusing.
- how to evaluate a string in an integer context: is "abc" 1 or 3 (strlen)? How about "123" ?
What do you mean by integer context? Like if (123 == "abcd") {...} ? 3+"3" ? Or when a function needs integer parameter but gets string for example? I am in favour of trying to convert the string to integer, and return an error when it is not possible. strlen() function can be also supported in the script, and called explicitly when needed.
- $v is 0 if v is not defined?
Note that if we do this it will work in all types of expressions, e.g. if string evaluates to strlen(string) in interger context then: 3+"abc" = 6 ; 3+ ""=3 ; 3+"9"=4 3+"0"=4.
Miklos
Andrei
_______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Miklos Tirpak writes:
I vote fore keeping the support for "if (@to.tag)" like expressions, and adding the extra functions for more precise checks if necessary. So a string value could evaluate to true if it exists and not "".
what if there is no to tag at all or if there is one, but its value is ""?
I think it is easier to read and understand "if (@to.tag)" then "if (!strempty(@to.tag))"
why don't you write 'if (@to.tag != "") ...'? that would be easy to understand. -- juha
On 04/24/2009 04:42 PM, Juha Heinanen wrote:
Miklos Tirpak writes:
I vote fore keeping the support for "if (@to.tag)" like expressions, and adding the extra functions for more precise checks if necessary. So a string value could evaluate to true if it exists and not "".
what if there is no to tag at all or if there is one, but its value is ""?
Both of them would return false. Btw, I do not think that empty value is allowed for to tag, it's a very rare case, and could be covered with some explicit check.
I think it is easier to read and understand "if (@to.tag)" then "if (!strempty(@to.tag))"
why don't you write 'if (@to.tag != "") ...'? that would be easy to understand.
We used to write this, but had lots of issues. The problem happens for example with @contact.uri.user, when there is no contact header. Unfortunately the select function can return and error instead of success with "" value in this case. (The can be also revisited) And 'if (@contact.uri.user == "")' would evaluate to false because the left had side value does not exist, which is wrong. Miklos
-- juha
Miklos Tirpak writes:
Both of them would return false. Btw, I do not think that empty value is allowed for to tag, it's a very rare case, and could be covered with some explicit check.
to me to tag was just an example of some variable.
We used to write this, but had lots of issues. The problem happens for example with @contact.uri.user, when there is no contact header. Unfortunately the select function can return and error instead of success with "" value in this case. (The can be also revisited) And 'if (@contact.uri.user == "")' would evaluate to false because the left had side value does not exist, which is wrong.
this is exactly my point. you have to first check if something exists before you start to compare its value to something. -- juha
Hi, On 04/24/2009 06:44 PM, Juha Heinanen wrote:
Miklos Tirpak writes:
Both of them would return false. Btw, I do not think that empty value is allowed for to tag, it's a very rare case, and could be covered with some explicit check.
to me to tag was just an example of some variable.
We used to write this, but had lots of issues. The problem happens for example with @contact.uri.user, when there is no contact header. Unfortunately the select function can return and error instead of success with "" value in this case. (The can be also revisited) And 'if (@contact.uri.user == "")' would evaluate to false because the left had side value does not exist, which is wrong.
this is exactly my point. you have to first check if something exists before you start to compare its value to something.
Yes, this could work, but than we need two checks in most of the cases: if (defined($v) && ($v != "")) {...} This is more precise indeed, but the script writer should not forget the extra checks. Regarding SER selects, if we go for this solution, I think we should revisit all the select functions. For example @foo.param.abcd should return "" only if the 'abcd' parameter of header 'foo' exists, but it's value is empty. Than we could simply check the existence of the parameter: if (defined(@foo.param.abcd)) {...} Miklos
-- juha
On Apr 27, 2009 at 11:55, Miklos Tirpak <miklos@iptel.org> wrote:
Hi,
On 04/24/2009 06:44 PM, Juha Heinanen wrote:
Miklos Tirpak writes:
Both of them would return false. Btw, I do not think that empty value is > allowed for to tag, it's a very rare case, and could be covered with some explicit check.
to me to tag was just an example of some variable.
We used to write this, but had lots of issues. The problem happens for example with @contact.uri.user, when there is no contact header. Unfortunately the select function can return and error instead of success with "" value in this case. (The can be also revisited) And 'if (@contact.uri.user == "")' would evaluate to false because the left had side value does not exist, which is wrong.
this is exactly my point. you have to first check if something exists before you start to compare its value to something.
Yes, this could work, but than we need two checks in most of the cases:
if (defined($v) && ($v != "")) {...}
This is more precise indeed, but the script writer should not forget the extra checks.
We could try some sane defaults (for if ($v)). For example that's what perl does: undefined "" string 0 other integer $foo eq undef true true false false false $foo == undef true true true true false $foo eq "" true true false false false $foo == 0 true true true true false bool($foo) false false true false true int($foo) 0 0 0 0 I str($foo) "" "" S "0" "I" Where string == non empty, non-numeric string. Strings that contain numbers are automatically converted to their corresponding interger value, e.g. int("3")=3, but int("a")=int("")=0. However we are severely impaired by having same comparison and same addition operators for both strings and intergers. E.g.: $a == $v is quite messy (what if $a==undef, what to convert $v to?).
Regarding SER selects, if we go for this solution, I think we should revisit all the select functions. For example @foo.param.abcd should return "" only if the 'abcd' parameter of header 'foo' exists, but it's value is empty. Than we could simply check the existence of the parameter: if (defined(@foo.param.abcd)) {...}
Note: right now defined @select is always true (and undefined select is always ""), but I'll change that. Andrei
Andrei Pelinescu-Onciul writes:
We could try some sane defaults (for if ($v)).
yes, in case there are some.
For example that's what perl does: undefined "" string 0 other integer
$foo eq undef true true false false false $foo == undef true true true true false
$foo eq "" true true false false false
if $foo is undefined, it is insane to me that it would be equal to empty string "" or 0. also comparing two undefined things should not result in true. what would make sense to me is that comparing an undefined thing to anything that is defined, would result in false.
$foo == 0 true true true true false
again "" == 0 makes no sense. -- juha
On 04/27/2009 04:18 PM, Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
We could try some sane defaults (for if ($v)).
yes, in case there are some.
For example that's what perl does: undefined "" string 0 other integer
$foo eq undef true true false false false $foo == undef true true true true false
$foo eq "" true true false false false
if $foo is undefined, it is insane to me that it would be equal to empty string "" or 0. also comparing two undefined things should not result in true.
yes, this is really strange indeed. And ("abcd" == undef) is also true according to the table.
what would make sense to me is that comparing an undefined thing to anything that is defined, would result in false.
I agree. Miklos
$foo == 0 true true true true false
again "" == 0 makes no sense.
-- juha
On Apr 28, 2009 at 09:53, Miklos Tirpak <miklos@iptel.org> wrote:
On 04/27/2009 04:18 PM, Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
We could try some sane defaults (for if ($v)).
yes, in case there are some.
For example that's what perl does: undefined "" string 0 other integer
$foo eq undef true true false false false $foo == undef true true true true false
$foo eq "" true true false false false
if $foo is undefined, it is insane to me that it would be equal to empty string "" or 0. also comparing two undefined things should not result in true.
Actually if you think in terms of the operators it's not. The operators forces conversion of its operands to the type it expects. so for eq (which used for string): $foo eq undef is in fact (str) $foo eq (str) undef , and (str) undef is "". With undefined you have 2 options: either have valid conversion to string and ints or bail out with an error. Since we cannot stop the script or abort(), even if we report an error we still have to come up with a result.
yes, this is really strange indeed. And ("abcd" == undef) is also true according to the table.
Bear in mind, that == in this case (perl) is an int operator, so "abcd" == undef is in fact (int) "abcd" == (int) undef and (int) "abcd" is 0 (int) undef is 0 => 0 == 0.
what would make sense to me is that comparing an undefined thing to anything that is defined, would result in false.
I agree.
I don't. We have special operators for checking if something is defined or not. If you don't use it you want implicit conversion. In almost all script languages, if a var is undefined then it's equal to "". If you think some other behaviour is better, please fill all the table and think also about normal operations, e.g. $v int+ $x, $v str+ $x. Bear also in mind that we support 2 types: int and str. We don't support bool (bool is int) so all logical expressions are evaluated to int (so you cannot say bool("a") == true but int("a")==0). Also think about how other scripting languages handle that. Andrei
Hi Andrei, On 04/28/2009 10:33 AM, Andrei Pelinescu-Onciul wrote:
On Apr 28, 2009 at 09:53, Miklos Tirpak <miklos@iptel.org> wrote:
On 04/27/2009 04:18 PM, Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
We could try some sane defaults (for if ($v)). yes, in case there are some.
For example that's what perl does: undefined "" string 0 other integer
$foo eq undef true true false false false $foo == undef true true true true false
$foo eq "" true true false false false if $foo is undefined, it is insane to me that it would be equal to empty string "" or 0. also comparing two undefined things should not result in true.
Actually if you think in terms of the operators it's not. The operators forces conversion of its operands to the type it expects. so for eq (which used for string): $foo eq undef is in fact (str) $foo eq (str) undef , and (str) undef is "".
With undefined you have 2 options: either have valid conversion to string and ints or bail out with an error. Since we cannot stop the script or abort(), even if we report an error we still have to come up with a result.
yes, this is really strange indeed. And ("abcd" == undef) is also true according to the table.
Bear in mind, that == in this case (perl) is an int operator, so "abcd" == undef is in fact (int) "abcd" == (int) undef and (int) "abcd" is 0 (int) undef is 0 => 0 == 0.
Yes, I understand, but == was not an int operator in SER so far. So the question is whether or not we want to change the script syntax, or shall we keep the support for the current scripts.
what would make sense to me is that comparing an undefined thing to anything that is defined, would result in false. I agree.
I don't. We have special operators for checking if something is defined or not. If you don't use it you want implicit conversion. In almost all script languages, if a var is undefined then it's equal to "".
OK, this could work also in SR. Let's decide whether or not we introduce another operator for string comparisons ('eq'), or stick to '=='.
If you think some other behaviour is better, please fill all the table and think also about normal operations, e.g. $v int+ $x, $v str+ $x. Bear also in mind that we support 2 types: int and str. We don't support bool (bool is int) so all logical expressions are evaluated to int (so you cannot say bool("a") == true but int("a")==0). Also think about how other scripting languages handle that.
What do you think about this? Undef is either 0 or "", and == is used both for string and int. undefined "" string 0 other integer $foo == undef true true false true false $foo == 0 true false false true false (The right value is converted to the type of the left value if necessary. So "0" == 0, but "" != 0.) bool($foo) false false true false true int($foo) 0 0/error I/error 0 I str($foo) "" "" S "0" "I" 0/error, and I/error means that the expression should be evaluated in the 'if' conditions, and in the mathematical expressions slightly differently: if (0 == "") -> false, (0 == "0") would be true. if (0 == "abcd") -> false if (1 == "1") -> true $v + "" -> $v -> I think we have no other choice. $v + "abcd" -> $v $v + "1" -> $v + 1 I do not whether or not it's close to any scripting language, feel free to tell me if it's a complete mess. But I think it's closer to the current SER script language at least. Miklos
Andrei
On Apr 28, 2009 at 13:09, Miklos Tirpak <miklos@iptel.org> wrote:
Hi Andrei,
On 04/28/2009 10:33 AM, Andrei Pelinescu-Onciul wrote:
On Apr 28, 2009 at 09:53, Miklos Tirpak <miklos@iptel.org> wrote:
On 04/27/2009 04:18 PM, Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
We could try some sane defaults (for if ($v)). yes, in case there are some.
For example that's what perl does: undefined "" string 0 other integer
$foo eq undef true true false false false $foo == undef true true true true false
$foo eq "" true true false false false if $foo is undefined, it is insane to me that it would be equal to empty string "" or 0. also comparing two undefined things should not result in true.
Actually if you think in terms of the operators it's not. The operators forces conversion of its operands to the type it expects. so for eq (which used for string): $foo eq undef is in fact (str) $foo eq (str) undef , and (str) undef is "".
With undefined you have 2 options: either have valid conversion to string and ints or bail out with an error. Since we cannot stop the script or abort(), even if we report an error we still have to come up with a result.
yes, this is really strange indeed. And ("abcd" == undef) is also true according to the table.
Bear in mind, that == in this case (perl) is an int operator, so "abcd" == undef is in fact (int) "abcd" == (int) undef and (int) "abcd" is 0 (int) undef is 0 => 0 == 0.
Yes, I understand, but == was not an int operator in SER so far. So the question is whether or not we want to change the script syntax, or shall we keep the support for the current scripts.
For now we could keep it, but for next releases we need some changes. We need at least different version for ==, != and + for integer and strings. Overloading them to work for both is just broken and it will lead to strange behaviour. Another important change would be typed variables and avps (we would be able to do much better error checking on the script and make life much more easier for script writers at the cost of only having to pre-declare the vars with the intended use type).
what would make sense to me is that comparing an undefined thing to anything that is defined, would result in false. I agree.
I don't. We have special operators for checking if something is defined or not. If you don't use it you want implicit conversion. In almost all script languages, if a var is undefined then it's equal to "".
OK, this could work also in SR. Let's decide whether or not we introduce another operator for string comparisons ('eq'), or stick to '=='.
I've introduced eq, ne for strings, ieq and ine for integers. The names are temporary as their intended use is testing (for possible introduction in the next-next release).
If you think some other behaviour is better, please fill all the table and think also about normal operations, e.g. $v int+ $x, $v str+ $x. Bear also in mind that we support 2 types: int and str. We don't support bool (bool is int) so all logical expressions are evaluated to int (so you cannot say bool("a") == true but int("a")==0). Also think about how other scripting languages handle that.
What do you think about this? Undef is either 0 or "", and == is used both for string and int.
undefined "" string 0 other integer
$foo == undef true true false true false
This is ok, this is the way it behaves now (on my type_conversion branch).
$foo == 0 true false false true false ^^^^^ this is not, but it's related to the string to int conversion (below)
(The right value is converted to the type of the left value if necessary. So "0" == 0, but "" != 0.)
bool($foo) false false true false true ^^^^^ we do not have boolean and I don't think introducing it would be a good ideea.
int($foo) 0 0/error I/error 0 I ^^^^^^^^^^^^^^^^ right now in my branch it works like this: at startup you'll get an error (if the type is known to be string). If the type is not known (avp pvar) => I can't tell if it's an error or not, At runtime it's 0 (for "", "abc") or I (for "123"). No error is generated (it wouldn't help anyway, it's too late).
str($foo) "" "" S "0" "I"
0/error, and I/error means that the expression should be evaluated in the 'if' conditions, and in the mathematical expressions slightly differently:
That's what I want to avoid, different behaviour.
if (0 == "") -> false, (0 == "0") would be true. if (0 == "abcd") -> false if (1 == "1") -> true
$v + "" -> $v -> I think we have no other choice. $v + "abcd" -> $v $v + "1" -> $v + 1
I do not whether or not it's close to any scripting language, feel free to tell me if it's a complete mess. But I think it's closer to the current SER script language at least.
I've attached a first draft describing how type conversion and operators work in sip-router. It describes the code on the andrei/type_conversion branch. If I won't get strong objections, I'll merge that branch into master (we can't waste too much time arguing, we need to have something sane and something that mimics perl behaviour as much as possible it should be at least good enough). If people are worried about specific ser or kamailio script snippets that won't work, then please provide some _simple_ test config that I can use. By simple, I mean something using very few modules (only xlog & pv would be ideal) and having something like: $var=expr_that_might_not_work; if ($var != expected_value ) xlog("L_CRIT", "BUG: sanity check 1 failed"); if ( expr2 != expectred_value) xlog("L_CRIT", "BUG: sanity check 2 failed"); a.s.o. We could collect them and use them for testing each time we do a change to expression evaluation. Andrei
missing attachement added. On Apr 30, 2009 at 12:53, Andrei Pelinescu-Onciul <andrei@iptel.org> wrote:
On Apr 28, 2009 at 13:09, Miklos Tirpak <miklos@iptel.org> wrote:
Hi Andrei,
On 04/28/2009 10:33 AM, Andrei Pelinescu-Onciul wrote:
On Apr 28, 2009 at 09:53, Miklos Tirpak <miklos@iptel.org> wrote:
On 04/27/2009 04:18 PM, Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
We could try some sane defaults (for if ($v)). yes, in case there are some.
For example that's what perl does: undefined "" string 0 other integer
$foo eq undef true true false false false $foo == undef true true true true false
$foo eq "" true true false false false if $foo is undefined, it is insane to me that it would be equal to empty string "" or 0. also comparing two undefined things should not result in true.
Actually if you think in terms of the operators it's not. The operators forces conversion of its operands to the type it expects. so for eq (which used for string): $foo eq undef is in fact (str) $foo eq (str) undef , and (str) undef is "".
With undefined you have 2 options: either have valid conversion to string and ints or bail out with an error. Since we cannot stop the script or abort(), even if we report an error we still have to come up with a result.
yes, this is really strange indeed. And ("abcd" == undef) is also true according to the table.
Bear in mind, that == in this case (perl) is an int operator, so "abcd" == undef is in fact (int) "abcd" == (int) undef and (int) "abcd" is 0 (int) undef is 0 => 0 == 0.
Yes, I understand, but == was not an int operator in SER so far. So the question is whether or not we want to change the script syntax, or shall we keep the support for the current scripts.
For now we could keep it, but for next releases we need some changes. We need at least different version for ==, != and + for integer and strings. Overloading them to work for both is just broken and it will lead to strange behaviour. Another important change would be typed variables and avps (we would be able to do much better error checking on the script and make life much more easier for script writers at the cost of only having to pre-declare the vars with the intended use type).
what would make sense to me is that comparing an undefined thing to anything that is defined, would result in false. I agree.
I don't. We have special operators for checking if something is defined or not. If you don't use it you want implicit conversion. In almost all script languages, if a var is undefined then it's equal to "".
OK, this could work also in SR. Let's decide whether or not we introduce another operator for string comparisons ('eq'), or stick to '=='.
I've introduced eq, ne for strings, ieq and ine for integers. The names are temporary as their intended use is testing (for possible introduction in the next-next release).
If you think some other behaviour is better, please fill all the table and think also about normal operations, e.g. $v int+ $x, $v str+ $x. Bear also in mind that we support 2 types: int and str. We don't support bool (bool is int) so all logical expressions are evaluated to int (so you cannot say bool("a") == true but int("a")==0). Also think about how other scripting languages handle that.
What do you think about this? Undef is either 0 or "", and == is used both for string and int.
undefined "" string 0 other integer
$foo == undef true true false true false
This is ok, this is the way it behaves now (on my type_conversion branch).
$foo == 0 true false false true false ^^^^^ this is not, but it's related to the string to int conversion (below)
(The right value is converted to the type of the left value if necessary. So "0" == 0, but "" != 0.)
bool($foo) false false true false true ^^^^^ we do not have boolean and I don't think introducing it would be a good ideea.
int($foo) 0 0/error I/error 0 I ^^^^^^^^^^^^^^^^ right now in my branch it works like this: at startup you'll get an error (if the type is known to be string). If the type is not known (avp pvar) => I can't tell if it's an error or not, At runtime it's 0 (for "", "abc") or I (for "123"). No error is generated (it wouldn't help anyway, it's too late).
str($foo) "" "" S "0" "I"
0/error, and I/error means that the expression should be evaluated in the 'if' conditions, and in the mathematical expressions slightly differently:
That's what I want to avoid, different behaviour.
if (0 == "") -> false, (0 == "0") would be true. if (0 == "abcd") -> false if (1 == "1") -> true
$v + "" -> $v -> I think we have no other choice. $v + "abcd" -> $v $v + "1" -> $v + 1
I do not whether or not it's close to any scripting language, feel free to tell me if it's a complete mess. But I think it's closer to the current SER script language at least.
I've attached a first draft describing how type conversion and operators work in sip-router. It describes the code on the andrei/type_conversion branch. If I won't get strong objections, I'll merge that branch into master (we can't waste too much time arguing, we need to have something sane and something that mimics perl behaviour as much as possible it should be at least good enough). If people are worried about specific ser or kamailio script snippets that won't work, then please provide some _simple_ test config that I can use. By simple, I mean something using very few modules (only xlog & pv would be ideal) and having something like:
$var=expr_that_might_not_work;
if ($var != expected_value ) xlog("L_CRIT", "BUG: sanity check 1 failed"); if ( expr2 != expectred_value) xlog("L_CRIT", "BUG: sanity check 2 failed");
a.s.o.
We could collect them and use them for testing each time we do a change to expression evaluation.
Andrei
_______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
i would prefer to have no automatic conversion of int to string or string to int or conversion of undefined variable to anything. it would be enough if there exist conversion functions int() and str() like in python. this would also greatly simplify the implementation. -- juha
On Apr 30, 2009 at 21:07, Juha Heinanen <jh@tutpro.com> wrote:
i would prefer to have no automatic conversion of int to string or string to int or conversion of undefined variable to anything. it would be enough if there exist conversion functions int() and str() like in python. this would also greatly simplify the implementation.
That would completely break current configs (which might not be a bad thing after all, but would make transition more difficult). I'm going to merge what I have right now and leave bigger changes for future releases (not the next release). Andrei
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. Cheers, Henning
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/
participants (5)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Henning Westerholt -
jh＠tutpro.com -
Miklos Tirpak