------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1447
--- Comment #8 from quetantofaz@??? 2014-02-26 15:39:09 ---
(In reply to comment #7)
> The ovector contains offsets, there is no string length. MARK is excellent for
> enumerations:
>
> /\d+(*:handleNumber)|\w+(*:handleString)/
>
> or simply (*:0), (*:1) and substract '0' (48 in ASCII) from the first character
> of the MARK to get the index, or a-z if you have more than 10 cases, or call
> atoi() if you have thousands of cases.
>
> Currently you only have one MARK. Maybe a multimark could extend it further
> (perhaps up to 9): (*MARK0:a), (*MARK1:b) or (*0:a) (*1:b) as a short from, but
> I am not sure we really need such extension.
>
An excellent reply. Thank you.
No string length, huh. Makes sense!
Two points:
1. It isn't clear how f.e. handleString() will continue, what it'll do. It
seems it'll either a) build a record, or b) direct the current parsing process.
Option b) doesn't interest me because I feel Perl 6 shows how to do things in a
better way. For a) it seems overkill.
2. Note that the matches-array in the format I suggested is complete in and by
itself. It perfectly defines the pattern matched and it can be passed along to
entirely different parts of the program, as a token. Its only failure is that
it isn't an object, but manually typed instead.
Note that the actual dispatch, based on the "type" of branch taken, could occur
in an different phase of the program, at the appropriate time.
It is my job to make the request clear, register it on your radar. I believe it
is done. Thanks for a great package :)
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
