| | 347 | =head3 So how do Captures work with Rules? |
| | 348 | |
| | 349 | In the context of rules, Captures are superclasses of Match. So in the example of: |
| | 350 | |
| | 351 | my $rv = ("x-y-z-moose" ~~ /(.)-(.)-(.)-<animal> :{ return give_birth(*$/) }) |
| | 352 | |
| | 353 | C<give_birth()> gets called with 'x', 'y', and 'z' as positional arguments, |
| | 354 | and :animal<moose> as a named argument. C<give_birth()> can return a Moose object - |
| | 355 | and C<$rv> is assigned a Capture object with the Moose object in its invocant slot. |
| | 356 | C<$rv> has the same positional and named slots as the Moose object - and you can |
| | 357 | retrieve the Moose back through C<$rv as Animal>. |
| | 358 | |
| | 359 | Nested captures in the rule then become nested Capture objects within positional |
| | 360 | slots in $/, which allows them to be retrieved as arguments for additional functions. |
| | 361 | And so you can bind annotated nodes of a tree to particular function calls, passing |
| | 362 | the data straight in thanks to the equivalence of Captures returned by rules and |
| | 363 | Captures used to invoke functions and methods. As such, Captures could be considered |
| | 364 | a natural data type for XML nodes, and provide considerable power for parsing DOMs using |
| | 365 | Rules, and providing native tree manipulations. |
| | 366 | |
| | 367 | |