[asterisk-dev] [design] Matching algorithm

[Tilghman Lesher]

On Tuesday 03 June 2008 14:25:12 Jay R. Ashworth wrote:
> On Tue, Jun 03, 2008 at 12:23:32PM -0600, Steve Murphy wrote:
> > On Tue, 2008-06-03 at 10:34 -0500, Tilghman Lesher wrote:
> > >
> >
> > I thought I'd weigh in on this, as I've done a share of pattern
> > matching hacking.
> >
> > IIrc, I'm pretty sure my fast pattern matcher does a pass over the
> > string and upcases all the NXZ's. This is in trunk and 1.6.0 at the
> > moment. If you guys decide that lowercase is not a matching pattern,
> > this will have ramifications on *that* code, and I'll have to mod it
> > to duplicate the old behavior.
> >
> > I'm willing to abide by whatever's decided, tho. It's a pretty minor
> > tweak to the code. (I believe/think/hope)
>
> So... do I have this straight:  The *functionality* of the characters
> doesn't change by case, only the sorting of the items they comprise?

The priority by which matches match first, if multiple patterns would
otherwise match a given extension.

> This was a wart, then, when it cropped up in 1.4?
>
> To answer your question from my perspective, given:
> > > 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?
>
> Unless I'm misunderstanding you, the latter alternative directly
> contradicts the assertion in the first graf: you can't.  If you think
> people are depending on the undocumented "override" behavior, then you
> have to maintain it.

I disagree.  If we fail to document a behavior, then it's accidental
functionality, and it's subject to change at any time.  Atis is going through
this now, in another thread, as he's hooking an AEL routine from ARA, a
behavior that we never documented would work, and upon looking back at
it, we would never want to support.  It's just too hairy a proposition that we
would support unintentional functionality (especially as it CAN be viewed as
a bug).

The design proposition by which I started this thread is the question of
whether we would WANT to support this functionality.  The consensus thus
far appears to be against supporting this functionality, and indeed, for
removing it altogether.

-- 
Tilghman