|laziness, impatience, and hubris|
getting more from __DATA__by Ctrl-z (Friar)
|on Mar 24, 2005 at 23:07 UTC||Need Help??|
It is quite often I find myself with the need to keep chunks of text along with a module or script - not enough to warrant extra files, but enough to make using quotes and heredocs quite ugly. After reinventing my favourite simple solution (again), I found myself wanting to encapsulate the functionality in a module - but being put off by the simplicity of the implementation. I realise modules dont have to be magic, but still...
Cut to the chase - I wrote the module. I have included the start of some POD
covering the general idea. Its all a bit rough'n'ready, but I would appreciate any opinions
at this stage (or just tales of weird uses of __DATA__ you like to employ ;-).
My meditations is this:
edit: updated POD to match code posted later
NAMETie::DATA - access named data segments in __DATA__ handle via the package variable %DATA
SYNOPSISuse Tie::DATA [[sub|scalar|regex], [sub|scalar]];
Tie::DATA provides a means to break a module or scripts' __DATA__ handle into named segments, accessible via the read-only package variable %DATA. Tie::DATA is not intended for configuration variables, but for medium-sized bodies of text that should be kept with the code (without being embedded in variable declarations).
%DATA's entries are created lazily; that is, when it is first used.
There are two stages to execution, both of which can be customized by arguments to use Tie::DATA
parsingBy default, Tie::DATA uses similar syntax as the __DATA__ token to seperate segments. Of course, what is a suitable seperator depends on the text being stored, so several likely defaults are provided:
It is important to remember that by default, segments cannot be nested - in particular, :xml cannot have attributes.
Full customization of parsing can be gained by passing either a regex or sub reference as the first argument:
The subroutine reference should return a list of key value pairs.
After parsing, if a callback has been registered as the second argument, then each Key-Value pair is passed to the callback function for further processing. This function is expected to return the actual Key-Value pair that will be used in %DATA.
For example, if you wanted to control how whitespace was treated for each segment individually, you might use something like:
There is no reason why the processing subroutine need be in the current module:
%DATA is read-only. Any attempt to modify it after the processing stage will cause the program to croak.