in reply to Prototype Killer

But why??

Whether prototypes are evil or possibly not, do you really want to do this to an existing script?

Among other possible problems, if you had code like this, you'd break it:

sub a($) { print @_,"\n"; } my @x=qw(1 2 3); a(@x);
After your "fix", this would print "123" instead of "3"...
--
Mike

Replies are listed 'Best First'.
Re^2: Prototype Killer
by tadman (Prior) on Sep 04, 2002 at 11:41 UTC
    What exactly would be the point of such a subroutine? That's pretty wacky stuff, you have to admit.

    It would be sensible to define any function like this:
    sub a { print $_,$/; } my @x = qw[ 1 2 3 ]; a(scalar(@x));
    Which is similar. I can't think of many examples of where a function would only care about how many elements, and not what they are.

    But anyway, as I said, it is a rudimentary script. YMMV. I found it handy at cleaning house on a whole whack of redundant prototypes in long scripts.
      That was just a simplified example. The point is that if you have a $ proto, arguments are evaluated in scalar context.

      What if someone's invoking a sub with localtime as an argument, for instance?

      I agree, it's possible that's not happening. But without a heck of a good test suite, I'd hesitate to make that kind of change on a project of any size. If there's a wantarray buried in a sub somewhere, it's going to make for a tough problem to debug...
      --
      Mike

        I agree with your assessment that it's limited in application. But as you said, if you have any functions like this, then you will have trouble. I know the code I'm working on isn't this way. I'm just too Lazy to go through and pick out each one of these little bundles of joy, seeing as how there's umpteen hundreds of them.

        You'll note that Perl is set on Kill (-pi), not Stun (-pi.bak). I don't care about backups because it's all in CVS, so you can check through your changes before committing.