Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Passing DATA filehandle to a module under strict

by blindluke (Beadle)
on Jan 26, 2012 at 09:56 UTC ( #950060=perlquestion: print w/ replies, xml ) Need Help??
blindluke has asked for the wisdom of the Perl Monks concerning the following question:

Enlightened Monks!

I tried to embed some information in a script, in a __DATA__ section, and then pass it to my config module of choice as a file handle. I can't physically separate the config from the script, so I tried this approach to achieve some kind of separation between the code and the config. The following code, however, produces an error.

#!/usr/bin/perl -w use strict; use Config::IniFiles; my $conf = Config::IniFiles->new( -file => DATA ); __DATA__ [SECTION] key =value

This code produces the following error:

Bareword "DATA" not allowed while "strict subs" in use at script.pl li +ne 31.

How can use the DATA section as a config file, while still using strict?

regards,
Luke Jefferson

Comment on Passing DATA filehandle to a module under strict
Select or Download Code
Re: Passing DATA filehandle to a module under strict
by choroba (Abbot) on Jan 26, 2012 at 10:01 UTC
    Does this work?
    my $HANDLE = *DATA; my $conf = Config::IniFiles->new( -file => $HANDLE );
Re: Passing DATA filehandle to a module under strict
by moritz (Cardinal) on Jan 26, 2012 at 10:02 UTC

      Enlightened Monks!

      Thank you, -file => \*DATA works fine.

      regards,
      Luke Jefferson

Re: Passing DATA filehandle to a module under strict
by Anonymous Monk on Jan 26, 2012 at 10:03 UTC
    Try a typeglob (shown in Config::IniFiles docs ), as in  *DATA or a reference to a typeglob (  \*DATA )
Re: Passing DATA filehandle to a module under strict
by JavaFan (Canon) on Jan 26, 2012 at 10:18 UTC
    How can use the DATA section as a config file, while still using strict?
    Answers to the first part of that sentence are already given. But you should realize that "strict" is a tool, not a goal. If the tool gets in your way of whatever you are doing, disable the tool for the time being.

    After all, the great prophet Larry has told us that the language should serve the programmer, and that the programmer should not be a slave of the language.

      If the tool gets in your way of whatever you are doing, disable the tool for the time being.

      Yes, definitely disable strict so you can save 1-or-2 characters , * or \*

        Yes, definitely disable strict so you can save 1-or-2 characters , * or \*
        Which part of Answers to the first part of that sentence are already given. was too difficult for you to grasp?
      If the tool gets in your way of whatever you are doing, disable the tool for the time being.

      I cannot agree with you on this one. I'd rather say, that if a tool, that is beneficial to the whole code, gets in the way of a small task, one should try to find out, whether there might be another way of doing this small task, without disabling the tool, and the benefits associated with its use.

      regards,
      Luke Jefferson

        and then, if you can't find "another way", disable the tool.
        I'd rather say, that if a tool, that is beneficial to the whole code, gets in the way of a small task, one should try to find out, whether there might be another way of doing this small task, without disabling the tool, and the benefits associated with its use.
        No, that doesn't make sense.

        You're going to spend more time (finding out whether there's a way of doing it while keeping your precious "strict" (or "warnings" or something else), for the sake of keeping your tool enabled, and likely to end up with pointless code -- after which chromatic starts nagging you about "synthetic code".

        If you're ever adding code just to silence a warning, you're doing it wrong. If you make code more complicated, just so you don't have to temporarely use "no strict", you're doing it wrong. If you're even going to spend time finding out whether you can do any of the above, you're not only doing it wrong, you're also wasting the money of whoever is paying you.

        # Bad code: $foo = ($bar // 0) + 4 if ($var1 // 0) == ($var2 // 0); # Better code: no warnings 'uninitialized'; $foo = $bar + 4 if $var1 == $var2;
        Feel free to draw some curly braces on your screen if one thinks this "better code" isn't part of some lexical block and is dumb enough to assume I advocate turning warnings off in the entire program.

      If the tool gets in your way of whatever you are doing, disable the tool for the time being.

      Indeed, but when disabling strict, try to take advantage of the fact that strict is scoped, so you should disable it in the smallest scope possible. And no strict can take various arguments to control which parts of it you're disabling.

      use strict; sub _foo { ... } LAX: { $caller = caller; no strict 'refs'; *{"$caller\::foo"} = \&_foo; }

      'refs' is pretty much the only part of strict that it's ever a good idea to disable.

      Without strict, it would have been passed as the string DATA, which would have resulted in an attempt to open Config::IniFiles's DATA instead of main's at best. Your point appears to be far off topic.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://950060]
Approved by marto
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (8)
As of 2014-07-10 02:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    When choosing user names for websites, I prefer to use:








    Results (198 votes), past polls