Oh come on.

Please read between the lines. The poster obviously doesn't know how DATA really works, and it's not how to do file IO he's asking about. He wants to learn about DATA and probably use it in his script and try it out. I think it's good to strive for greater understanding. If the problem is that you don't think he should be doing that by himself then just explain why, and then give him the alternative safe solution.

Inline::Files is good and all, but it can also be total overkill. I like Inline::Files when I want to have several DATA filehandles, but when you just want one the only thing that differes DATA from any other filehandle is that it's preopened and that it's sought to some non-BOF location.

Inline::Files plus Inline::Files::Virtual is about 500 lines of Perl, using tieing and AUTOLOADing, fiddles with the CORE::GLOBAL namespace, and utilizes the Filter module--which is XS.

I just wrote a program that checks the difference between a perl -e0 and perl -MModule -e0 on ActivePerl 5.8.0 build 806. The numbers in parenthesis in the approximate line count; POD, __END__/__DATA__, comments, and blank lines stripped (all pretty imperfectly done). The last number is the sum of the above. Empty (with my definition of empty) packages are filtered out.

Here's the output for Inline::Files:

New packages:
        AutoLoader
        Carp
        Config
        Cwd
        DB
        Data::Dumper
        Dos
        EPOC
        Exporter
        Filter::Util::Call
        Inline::Files
        Inline::Files::Data
        Inline::Files::Virtual
        Mac::FileSpec::Unixish
        VMS::Filespec
        XSLoader
        base
        fields
        strict
        vars
        warnings
        warnings::register
New files:
        ( 117) AutoLoader.pm
        (  41) Carp.pm
        (1122) Config.pm
        ( 325) Cwd.pm
        ( 125) DynaLoader.pm
        (  59) Exporter.pm
        (  33) Filter/Util/Call.pm
        ( 139) Inline/Files.pm
        ( 351) Inline/Files/Virtual.pm
        (  55) XSLoader.pm
        (  40) base.pm
        (  21) strict.pm
        (  39) vars.pm
        ( 316) warnings.pm
        (  26) warnings/register.pm
        (2809)
[download]

Now compare this to

    my $BOF = tell DATA;
    open my $data, '+<', $0 or die ...;
    seek $data, $BOF, 0 or die ...;
[download]

and pretty much all you need to remember is that BOF isn't 0 but $BOF.

I'm surprised to see you give this advice, since I've seen you elsewhere advocate to not invoke modules when they mean "unnecessary" overhead: "the code I posted elsewhere in this thread copies the method of the module, without even having to invoke the overhead of the module". In fact, I even disagree with you there, and think that constant.pm should be utilized there. :-) Funny, heh.

Not without evil and hackery. Unless you're up to source-code rewriting this avenue isn't open to you. Now if it is... I'll tell you a story or two that'll get you going in the right direction.

Puuuuhhhlease. Not the "it's a module" argument again. It's pure Perl... just copy it into your distro. Or use PAR. Or look at the source code and cannibalize the parts you need.

But pllllllleeeease let's stop with the "I can't use this because it's a module instead of some idea about code" whining.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Puuuuhhhlease. Not the "people are ignorant" reaction again. No one can see your face and see how annoyed you are. That's good, and there's no reason to put it to print. If you have a problem, just write the problem and don't make a charade. How many times have you told aquarium about this? It's OK to say "Sure you can, that's no problem. Take a look at this document that explains how and why."

But pllllllleeeease let's stop with the "I've told hundreds of users about this, so you too should know" whining.

ihb

(Yes, I've read your disclaimer.)