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)).
regards klaus
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev