Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
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 browsing the Monastery: (8)
As of 2015-07-03 13:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (53 votes), past polls