20 Feb
2009
20 Feb
'09
3:03 p.m.
On 20-02 12:22, Andrei Pelinescu-Onciul wrote:
On Feb 20, 2009 at 11:15, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
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 is similar to the difference between
if (method == INVITE) and if (method == "INVITE")
I guess most people won't be able to tell you the difference if you asked them.
I would not assume that mixed integers and strings are 99% errors, we don't
really know what people have in their configuration scripts and why, so this
assumption is IMHO not justified.
Hello Andrei,
On 02/20/2009 12:50 AM, Andrei Pelinescu-Onciul wrote:
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). [...]
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? I still think that using a different switch() name for
strings will be
less confusing (e.g. switch() for integers and match() for strings).
Yes, I like match for strings better too, especially if regular expression
matching is involved.
Any opinion on how to differentiate regular
expressions from strings?
Right now a '/' in front means a regular expression (but there's no way
to specify case insensitive match for example).
How about enclosing regular expressions in a pair of // like in awk or
perl. It would be possible to introduce a flag for case-insensitive matching, something
like:
i/regex/
For example:
case i/From/:
my two cents, Jan.