in reply to passing and processing code references

Why would you like to do this?

You could take a string and do an eval on it. That will be slow, can lead to an unmaintainable design, etc, but you can.

However I would strongly prefer using an anonymous function and I am curious why you do not. Remember, focus on what it is that you want to accomplish, not how you want to accomplish it. So make it be an anonymous function, and either use local on $file, or pass it as an argument to the function.

Personally I would pass it as an argument. If I want flexibility, then pass a hash of arguments...

  • Comment on Re (tilly) 1: passing and processing code references

Replies are listed 'Best First'.
RE: Re (tilly) 1: passing and processing code references
by princepawn (Parson) on Oct 11, 2000 at 17:06 UTC
    What's wrong with a Perl block? grep takes a block. Here's the answer: 
    sub x(&) {
    my $coderef = shift;

    use Data::Dumper; print Data::Dumper->Dump([$coderef],['coderef'])
+;

    {
    $_ = 'bumpkin';

    $coderef->();
    }
}

x { print "$_.YYY" };

    [download]
[reply]
[d/l]
      Several things are wrong wth a Perl block done that way.

      First of all read FMTEYWTK About Prototypes In Perl. Everything in there about prototypes applies. I don't like them, and don't like them for a reason.

      Secondly you now have order of declaration issues. If the prototype is not declared before the code that you use, then it works one way. If it is then it works another.

      Thirdly what happens later when you want to modularize, move code elsewhere and import with Exporter? If you move code from one package to another, then code that had worked through setting a global will break because the global is in the wrong blockpackage (minor fix, sorry). Do you have a guru on staff? Because most people are unlikely to look at that problem and know to check caller and mess with globals in your caller's namespace. (And games like that quickly leads to messes.) Oh, but you tested with $_ (which you didn't localize I note) which is always in package main. So your tests wouldn't pick that up. The moral? Don't use special variable names for testing scoping issues!

      Fourth Tom C mentioned bugs with the & prototype. What kind of bugs you ask? Well there is a deep problem with braces being overloaded. They can be interpreted as a block to be turned into an anon sub, a block to execute inline, or an attempt to produce an anonymous hash. Mix this with disambiguating core functions from user functions and you get quite a mess of potential ambiguities to parse! Yes, I know that some core functions do this already. But the list of ones that do is small, and there is no ambiguity between them being core and user. Like globals, special behaviour is OK in controlled amounts but should not be used throughout your design at risk of insanity.

      Now all of this is what you lose, what do you gain?

      Being able to omit 4 characters. Just type "sub " in front of your block and it works without prototypes. Without parsing ambiguity. Without declaration issues. OK, so if you use globals then you are still in trouble, but an ever-expanding web of globals to keep track of is a sign of a poorly thought through design.

[reply]

In Section Seekers of Perl Wisdom