[SR-Dev] script parsing: string switch support

[Andrei Pelinescu-Onciul]

On Feb 20, 2009 at 16:01, Andrei Pelinescu-Onciul <andrei at iptel.org> wrote:
> On Feb 20, 2009 at 15:54, Henning Westerholt <henning.westerholt at 1und1.de> wrote:
> > On Friday 20 February 2009, Andrei Pelinescu-Onciul wrote:
> > > [..]
> > > > > (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).
> > 
> > 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. ;-)
> 
> Good luck with runtime debugging then :-)
> 
> > 
> > > 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. 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 
> 
> Sorry, but that's just broken (mixed expressions).

I don't really understand this argument. Leaving performance and
optimizations aside, do you really think is better to guess what the
user might have wanted in ambiguous cases, rather then through an error
and point him to explain more clearly what he wants (e.g. use  match()
instead of switch() for strings, or use typed variables)?
With the general approach advocated by some people here, a small error
when writing the script (e.g. forgetting some "") will be visible only at 
runtime (and depending where that error is it could take weeks until
that branch of the config is reached and the error is triggered).
I think this is much worse then having to add a little more "details" to
the script (which BTW wouldn't make it any more difficult then any
common programming language).

I'd rather have to declare even variable types (e.g. int $a), rather
then debugging strange bugs in a script, because I used a var that
happens to get a string value at runtime.

In brief I much prefer adding to the script if this helps check its
correctness at sr -cf time, rather then trying to be excessively friendly
and leaving a lot of potential script bugs pass-through.
The ability to be able to tell that the script would behave correctly
(as his writer wanted it to) and eliminate ambiguous cases is more
important than trying to keep a very reduced script and guessing what
the writer really wanted.


Andrei