20 Feb
2009
20 Feb
'09
5:11 p.m.
On 02/20/2009 05:05 PM, Daniel-Constantin Mierla wrote:
On 02/20/2009 04:54 PM, Henning Westerholt wrote:
... re-reading ... looks like half explained, so here is more ... the
flags parameter was intended to specify what type or value to get from
PV (int or str), so the PV callback function does not need to provide
the string representation if there is an int behind PV and int is
required for the operation.
Now there are some operations done for nothing, inherited because of PV
roots in xlog where everything needed to be string represented.
On Friday 20 February 2009, Andrei
Pelinescu-Onciul wrote:
this is because the most of PVs have the string value as well.
However, I consider that misleading, although I worked a lot the switch.
It was planned to fix as the PV callbacks had a parameter for flags.
[..]
Hi Andrei,
the amount of detail in the config language is IMHO important. The developers
must document and test every single statement. Every user must read, learn
and memorize each statement too.
I regulary need to check the documentation for some special cases in the
config when i get asked for a review of some changes a co-worker did, because
he still feel not completely confortable after years of administrating SER*
systems. During all the time i spend on user channels i really rarely heard
the that our server is to slow (only when some real bottlenecks were
involved, like DB), the common complain is that the learning curve is too
steep. Perhaps i'm lazy, but i'd not say that everybody out there is it
too. ;-)
> (1) - could be changed in some cases (e.g.
string case with some int
> label allowed, which could be automatically converted to string), but I
> think it would too confusing and I disallowed it (in general having
> mixed types in a switch() are 99% an error).
>
>
I would suggest to convert numbers to strings in this case automatically.
For most people things get more confusing with the increasing amount of
details they have to remember about the configuration language.
This would only make sense if we use match() for strings and switch()
for ints. Otherwise it would be too confusing.
Anyway I don't think the amount of details of the configuration language
is ever a problem, as long as one gets meaningful error messages when
checking the config (and before ser startup).
The other approaches trade-off less config
details for guessing what the
user intended, which IMO is much more dangerous. Is much better to get
meaningful errors when running ser -cf ... , then getting unexpected
behaviour at runtime (a very good example for this are typed variables
vs. untyped ones or operators that try to guess the type and assume the
user made the right choice).
I just checked in kamailio, we don't throw an error if one mix strings
and
ints in a switch case.
I would prefer single type case value, and report
errors at startup - it
is easier to check and optimize. It is better to use a transformation to
convert the value to a specific type (e.g., {s.int}).
I mean, use transformation or equivalent to the variable used in
'switch(var)'.
Cheers,
Daniel
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
We also check for a correct type of an integer
in a
mixed expression, e.g. if its a valid int value. I don't think that we
convert them implicitly, as many pseudo-variables hold internally both a
string and a integer value, so mixed expression will work just as intended in
most cases.
Cheers,
Henning
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev