[asterisk-dev] [design] Matching algorithm

[Tony Mountifield]

In article <48456A0A.3060806 at digium.com>,
Russell Bryant <russell at digium.com> wrote:
> Tilghman Lesher wrote:
> > In the matching code, however, there is an anomaly, in that if you use the
> > lowercase versions of the common classes, that is "n", "x", and "z", they
> > currently match earlier than more specific matches.  That is, "_x" matches
> > before "_[1-4]", which matches before "_X".
> > 
> > Now, we are not going to change this behavior in 1.4, certainly.  That has the
> > potential to break currently working dialplans, and where we can reasonably
> > foresee such an outcome, we'd like to avoid that.
> > 
> > However, this is certainly an unintended behavior, and the question then
> > becomes, do we document this as a way to override the pattern match
> > algorithm, or do we change the lowercase class letters to behave the same
> > as the uppercase class letters?
> 
> My opinion is that treating _x and _X is probably an accidental 
> oversight, and the code should be updated to treat them the same.

I originally got bitten by not realizing that lower-case n, x and z were
special (all the examples in extensions.conf use upper-case). I would use
lower-case alpha prefixes to extension numbers for certain kinds of dialplan
processing, and the found this didn't do at all what I expected it to:

exten => _main-X.,1,Set(CONF=${EXTEN:5})

So my preference would be for only upper case N, X and Z to be special,
and lower case to be literal characters. I don't know how many Asterisk
users do _nxxnxxxxxx instead of _NXXNXXXXXX

Cheers
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org