[SR-Dev] script parsing: string switch support

[Jan Janak]

On 20-02 14:25, Andrei Pelinescu-Onciul wrote:
> On Feb 20, 2009 at 14:03, Jan Janak <jan at iptel.org> wrote:
> > On 20-02 12:22, Andrei Pelinescu-Onciul wrote:
> > > On Feb 20, 2009 at 11:15, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
> > > > Hello Andrei,
> > > > 
> > > > On 02/20/2009 12:50 AM, Andrei Pelinescu-Onciul wrote:
> > > > >[...]
> > > > >
> > > > >script parsing: string switch support
> > > > >  
> > > > that's great, thanks. From the next example, to understand the the case 
> > > > can take expression that evaluates to static strings or integers?
> > > 
> > > Yes.
> > > There are the following restriction:
> > > 
> > > - case labels must be static (no vars allowed)
> > > - in the same switch you can have only one type of case labels: strings
> > >   or integers (1)
> > > - the first case label sets the required type for all the others
> > >  (so if your first case label is a string => all the other must be
> > >  strings, if it's an integer all the other must be integers).
> > > 
> > > (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).

OK, so if the script writer writes something like:

  switch(@from.uri.user) {
  case "abc": ...
  case 100: ...
  case "foo" ..
  }

This is obviously a string based switch. What would you want to do with the
second (integer) case? Report an error? Or convert it to string, making it
equivalent to:

  switch($foo) {
  case "abc": ...
  case "1": ...
  case "foo" ..
  }
  
This is the case we are talking about, right?

  Jan.