[SR-Dev] operators and variables

Klaus Darilion klaus.mailinglists at pernau.at
Thu Dec 11 22:25:31 CET 2008

Hi Andrei!

Thanks for all this stuff.

IMO . instead of + for strings is fine.

I do not like eq/ne but if this is useful for optimization I can learn ;-)

I would not introduce too much compatibility stuff. If we (Kamailio) 
switch to a new core IMO it would be OK to start with clear syntax 
avoiding old style syntax which will be removed anyway.

Regarding strings. I think we also could address the NULL issue: 
difference of empty string versus undefined string (e.g. an undefined 
avp or a not existing pv like $hdr(Foo-Bar-XYZ)).


Andrei Pelinescu-Onciul wrote:
> It would be better to have different operators for strings and for
> integers. Right now we have '+', '==' and '!=' that can be used both for
> strings and integers. The problem with this approach is that it makes
> some optimizations impossible, especially when combined with dynamic
> typed variables (avps or pvars). '+' is especially bad because one
> can tell what type ($v + x) has only at runtime.
> I think having perl like operators would help a lot:
> - '.' for string concatenation (instead of reusing '+'), e.g.: 
>  $v= "foo" .  "bar"
> - 'eq' instead of == for strings, e.g.: $v eq "bar" 
> - 'ne' instead of != for strings, e.g.: $v ne "bar"
> We could support them right now in parallel with the old ones and 
>  obsolete +, ==  and != for strings in the future (but that means we
>  still cannot optimize '+' in all the cases) or switch right now
> (maybe with some old compat switch which will support old scripts
> style).
> The question is how much are they used right now. While I think '==' and
> '!=' are used quite often, I'm not sure about '+' for strings (and '+'
> is the most important anyway).
> Note: we can still support '==' and '!='  for condition tests not
> involving variables (e.g. method=="INVITE", uri=="sip:foo" a.s.o.).
> Another advantage that this change would bring is better type checking
>  at startup (more errors flagged without having to run the script) and
>  possible implicit conversions (e.g. int to string or string to int) if
>  we decide to support them.
> Any comments?
> In the future it would also be much better to have typed script vars
> (e.g. int $var1). This would help a lot in checking the script for
> correctness. With the dynamic typed vars, one has to run the script to
> find errors. It would also help in optimizing, but not so much if we
>  separate the operators, like above.
> Andrei
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

More information about the sr-dev mailing list