Beefy Boxes and Bandwidth Generously Provided by pair Networks DiBona
There's more than one way to do things
 
PerlMonks  

Re: subroutine prototypes still bad?

by dmitri (Curate)
on Jun 13, 2007 at 01:37 UTC ( #620858=note: print w/ replies, xml ) Need Help??


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 { };
There are probably other examples. Of course, you should not use prototypes unless you know exactly why you are using them.


Comment on Re: subroutine prototypes still bad?
Download Code
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.

    ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

      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

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.

Re^2: subroutine prototypes still bad?
by ikegami (Pope) 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; }

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

      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.

        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.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (5)
As of 2014-04-20 21:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (487 votes), past polls