in reply to Re: Automatically add all defined functions to your @EXPORT
in thread Automatically add all defined functions to your @EXPORT

our @EXPORT = do {
    no strict 'refs';
    grep {
        !/^_/
    } grep {
        defined &$_
    } keys %{ __PACKAGE__ . '::'};
};

[download]
Well, I was envisioning something more along the lines of: 
our @EXPORT = do {
    no strict 'refs';
    grep {
        defined &$_ and not /^_/;
    } keys %{ __PACKAGE__ . '::'};
};

[download]
I mean, you already have a grep there. Use it. {grin}

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

Replies are listed 'Best First'.
Re^3: Automatically add all defined functions to your @EXPORT
by dragonchild (Archbishop) on Jun 21, 2005 at 14:37 UTC
    This is an interesting style difference. I prefer putting one very specific item per map or grep. I find it makes both comprehension and maintenance easier in the long run. Maybe, this is a meditation in the making?
    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]
      I prefer putting one very specific item per map or grep.

      I don't get the logic of this. (That doesn't mean you should change it, I'd just like to understand it).

      You (probably) wouldn't code: 

      if( $var == 1 ) {
    doSomething();
}
if( $var == 1 ) {
    doSomethingElse();
}

      [download]

      Instead of 

      if( $var == 1 ) {
    doSomething();
    doSomethingElse();
}

      [download]

      Or 

      if( $var1 == 1 ) {
    if( $var2 == 2 ) {
         doSomething();
    }
}

      [download]

      In preference to 

      if( $var1 == 1 && $var2 == 2 ) {
     doSomething();
}

      [download]

      (would you?).

      So why the difference about combining the conditional in grep?

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
[reply]
[d/l]
[select]
        if( $var1 == 1 ) {
    if( $var2 == 2 ) {
         doSomething();
    }
}

        [download]
        In preference to 
        if( $var1 == 1 && $var2 == 2 ) {
     doSomething();
}

        [download]
        (would you?).

        Actually, I quite often find that the first of these two is exactly what I want as it makes what I'm doing much more clear. Othertimes, I use the latter. It really depends on whether the two tests are related or not, as well as whether there are other things I want to do in the $var==1 case but only if $var2!=2.

        So I often find myself writing a grep of a grep. Or a grep of a map of a map of a grep. Or a map of a grep of a grep. Or ... when a single map may just do fine.

        Your first example, having two if's to check the same thing, isn't really analogous to combining grep's since each grep is checking different things.

[reply]
[d/l]
[select]
        Because it's apples and oranges. doSomething() and doSomethingElse() aren't related via a pipeline, which the conditionals in grep are. So, by placing unrelated conditionals in their own greps, I give myself the opportunity to throw a map in there, if I feel like it. Putting them in the same grep removes that possibility.
        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]
        I don't get the logic of this.

        As an occasional user of multiple greps, I find

        @var = something1 grep {
         something2 &&
         something3
       } map {
         something4
       } keys %something5;

        [download]

        less readable than

        @var = something1
       grep { something2 && something3 }
       map  { something4 }
       keys %something5;

        [download]

        But sometimes, something2 && something3 is too long, so I break them down into:

        @var = something1
       grep { something2 }
       grep { something3 }
       map  { something4 }
       keys %something5;

        [download]

        And yes, I sometimes do

        if( $var1 == 1 ) {
    if( $var2 == 2 ) {
         doSomething();
    }
}

        [download]

        in preference to

        if( $var1 == 1 && $var2 == 2 ) {
     doSomething();
}

        [download]

        when the condition becomes quite long.

[reply]
[d/l]
[select]

In Section Cool Uses for Perl