Gabriel Berriz wrote:
I understand this is a FAQ but I have not been able to find the
answer: is there a way to include chunks of POD within another POD,
Nope.
But the idea seems too obvious for it not to have been implemented
by now.
Sometimes an idea is obvious while its implemantational problems are not
so obvious. Obviousness is tricky. But that bit of philosophizing aside...
I remember years ago having some compelling-seeming counterargument to
having an "include this" directive, but I (quite frustratingly) can't
remember anymore what it was. I think I might have been worried about
people including /etc/passwd; and if we forbid absolute pathnames, then
they would include "../../../../../../etc/passwd", or the like. So
maybe either they have to be files from the same directory, and/or they
would have to be modulenamish-specs, like "This::That::Whatever", where
that would mean the first $_/This/That/Whatever(\.pod|\.pm|something??}
in @INC.
Also, I really doubt you'd want this to be a N<...> formatting code.
Instead, I'd suggest a =foo directive. And this also brings up the
possibility of including a part of a given file, by line range (easy) or
maybe by being between lines somehow marked as being start-of-thingy-A
and end-of-thingy-A. (This is a bit harder to implement, but sure could
be handy.)
And logically, I guess the inclusion would have to happen at parse-time
-- we couldn't very well turn "=include whatever" into a construct that
meant the same thing in the target language, given that few target
languages have such a construct anyway.
Thoughts, anyone? Reductiones ad absurdum? Cheers?
Incidentally, this is tangential to, but quite distinct from the problem
of saying "and now drop in the image foo.png", where you're doing
something that's like inclusion, but not like inclusion in the sense we
just talked about above. In this case of "=for image thingy.png" or
anything similarly semihypothetical, we have a similar problem with
pathnames and whatnot -- but in that case it's messier:
With some output formats (like RTF or PDF) you drop in some form of the
raw image data; but troublingly, in other formats (HTML comes to mind
most), you /can't/ drop in the raw image data, so there has to be
particularly clever changes to the pathname -- not only do you have to
figure out how to resolve "foo.png" to an actual file, but then you have
to figure out how to turn that into something that will make sense in a
<img src="_"> for whatever purposes the user has in mind. This is all
in the way of combining a desire to make implemantational notes, with a
harrowing lack of caffeine.
--
Sean M. Burke http://search.cpan.org/~sburke/
