Message94045
Summary of your points with my responses :
> 1) it doesn't exist in any other implementation that I know;
That's exactly why I proposed to discuss it with the developers of other
implementations (I cited PCRE, Perl and PHP developers, there are
others).
> 2) if implemented as default behavior:
> * it won't be backward-compatible;
Wrong. This does not even change the syntax of regualr expressions
themselves.
> * it will increase the complexity;
Wrong. All the mechanic is already implemented: when the parser will
store string index positions for a matched group it will just have to
append a pair in the list stored in MatchObject.group(index) (it will
create the list if it is not ealready there, but it should be already
initialized to an empty list by the compiler) when the flag.R is set,
instead of overwriting the existing pair without wondering if there was
already another occurence of the same capturing group.
> 3) it will be a proprietary extension and it will reduce the
compatibility with other implementations;
Already suggested above. This will hovever NOT affect the compatibility
of existing implementation that don't have the R flag.
> 4) I can't think to any real word situation where this would be really
useful.
There are really a lot ! Using multiple split operations and multiple
parsing on partly parsed regular expressions will not be a solution in
many situations (think about how you would perform matches and using
them that in 'vi' or 'ed' with a single "s/regexp/replacement/flag"
instruction, if there's no extension with a flag and a syntax for
accesing the individual elements the replacement string). |
|
Date |
User |
Action |
Args |
2009-10-14 22:47:31 | verdy_p | set | recipients:
+ verdy_p, ezio.melotti |
2009-10-14 22:47:30 | verdy_p | set | messageid: <1255560450.67.0.128968211077.issue7132@psf.upfronthosting.co.za> |
2009-10-14 22:47:29 | verdy_p | link | issue7132 messages |
2009-10-14 22:47:28 | verdy_p | create | |
|