in reply to subroutine prototypes still bad?

It really depends on what you are doing. Some of the most useful things cannot be done without prototypes -- such as the wonderful Error.pm module that provides this syntactic sugar: 
try {
  try($something);
} catch Exception with {
};

[download]
There are probably other examples. Of course, you should not use prototypes unless you know exactly why you are using them.

Replies are listed 'Best First'.
Re^2: subroutine prototypes still bad?
by diotalevi (Canon) on Jun 13, 2007 at 07:27 UTC

    It's gotten slightly better due to dave_m's work but what you wrote is usually a memory-leak magnet. Error.pm is a horrible module just because of the closure related leaks.

    ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

[reply]
      Are you referring to the try inside a try? That inside "try" is meant to be some other function call. :)

      I have used Error.pm in long-running network daemons without many problems. I am aware that closures may cause memory leaks, but haven't run into one related to Error.pm

[reply]
Re^2: subroutine prototypes still bad?
by ikegami (Patriarch) on Jun 13, 2007 at 14:06 UTC

    That's actually a good example of why prototypes are *bad*. It looks so much like normal Perl code, one might be tempted to return from the catch block. 

    sub {
   try {
      ...
   } catch Exception with {
      return 0;
   };
   return 1;
}

    [download]

    However, a return in catch block only exits the catch block! The above function would always return 1.

[reply]
[d/l]
[select]
      I think it depends on what you are used to. I recently had to write some Java code, and I found myself putting 'return' statements outside of try/catch, even though it's fine in Java.

      Since I use mostly Perl, this behavior does not confuse me at all.

[reply]
        To me, that sounds like you're doing somthing so dangerous that you won't even do it in a language where it's safe in fear of getting it wrong in Perl.
[reply]
Re^2: subroutine prototypes still bad?
by DrHyde (Prior) on Jun 13, 2007 at 09:23 UTC
    Hear hear. I've needed them exactly once (in NestedMap) and a good rule of thumb is to not write any code that you don't need.

    And before anyone says "why do you use strict and warnings then" - I need them to save me from my own stupid errors. I suppose that in theory I could remove them from my modules once they pass all their tests, but that means I have to put them back in when I change stuff later, and it also supposes that my tests are perfect.

[reply]

In Section Seekers of Perl Wisdom