Re: [boost] [Review] xpressive

From: Daryle Walker (darylew_at_[hidden])
Date: 2005-09-18 14:31:05

On 9/16/05 11:44 AM, "Eric Niebler" <eric_at_[hidden]> wrote:

> Daryle Walker wrote:
> 
>> On 9/15/05 1:10 PM, "Eric Niebler" <eric_at_[hidden]> wrote:
>> 
>>> In practice, the only reason why you might iterator over all sub-matches is
>>> to print them out. Otherwise, the sub-matches are  accessed randomly,
>>> because (for example) the 1st sub-match is a date and the 3rd sub-match is
>>> an email address, and I'm not interested in the 2nd. See?
>> 
> <snip>
>> 
>> It looks like the current setup is not STL-friendly. Most of the "what"
>> list is one type of thing, the in-order pieces of the regex parse. The
>> first item of the list doesn't match that pattern (since it's the whole
>> parse). I'm guessing that this "old" way wasn't a problem because people
>> expected 1-based arrays, so the 0-index could be special. That doesn't
>> work
>> in a 0-based array culture, like C++ (or C). C++ people would expect the
>> 0-index element to match the general rule of the list. This mixing of
>> element types mixes concerns (violating "keep it simple, silly"). A
>> STL-friendly alternative would to have separate member functions for the
>> whole-parse and the list-of-parse-pieces, then have a special function
>> (member or non-member) that generates a regex-culture combined list.
>> 
> 
> I agree, if we we're only concerned about satisfying people familiar
> with C++ culture. But we are also trying to satisfy people familiar with
> regex culture. Every regex package out there I know of that supports
> back-references begins numbering captures at 1. I don't know why. But I
> do know that to break with that tradition now would cause massive
> confusion. Besides, I'm trying to minimize the differences between
> xpressive's interface and TR1 regex.

I wasn't considering back-references.  Does the list have to be tied to
back-references at this level?

> Is it a wart? OK, I agree. But frankly, I don't feel that this is an
> ugly enough wart for me to break with established practice.

But we should strive for an optimal interface, and then go back for any
"necessary" warts.  Since the nature of the 0-element is different from the
rest of the elements, I'm guessing that you generate that element in a
different manner than the others.  Is that correct?  If so, then you're
handling the elements differently anyway in your internal computations and
just merging them together at the user level.  You already did the work for
what I asked for; you're just doing extra work in hiding it.

Didn't the "old" way just use numeric indices, never going through the list
via single-step iteration?  So there was never a mixed-metaphor problem that
we have now.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com