Re^2: Why are 5.10's named captures read only? (step 3)

[tye]

Yes, indeed.

However, just like exposing only the string value of the named captures (as Perl 5.010 does) is convenient (for the user) but doesn't allow for the full abstraction of the feature (leaving no way to reliably find the offsets), so too would exposing the offsets not be the full abstaction and would still leave off a useful feature.

I'd like a way to (reliably) get at the number of the (numbered) capture that matches the named capture. That would allow one to then get at the offsets for any named capture which would then allow one to get at the substring matched.

I may end up parsing the regex myself, since I also would like to know when a capture is part of a look-ahead or look-behind. But the regex syntax has had so many enhancements added recently that parsing regexes currently looks like something that will require timely maintenance.

[ambrus]

I don't really understand how exposing the offsets and length would not be the full abstraction. Exposing the number of the numbered capture might still be a better interface even that way.

[tye]

I don't really understand how exposing the offsets and length would not be the full abstraction.

Given a way to look up the number of a named match, it is easy to precisely determine the offsets (it is just an array look-up in @+ and @-). Just having a way to look up the offsets doesn't allow you to reliably determine the number of the match.

So I would prefer that the mapping from name to number be exposed over the mapping from name to offsets. And one more hash that you use to look up offset inside of @+ and @- almost seems a better interface than exposing a pair of hashes or a hash that contains values that are two-element arrays anyway.