home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / perl / 5534 < prev    next >
Encoding:
Text File  |  1992-08-26  |  1.8 KB  |  42 lines
  1. Newsgroups: comp.lang.perl
  2. Path: sparky!uunet!usc!sol.ctr.columbia.edu!destroyer!ubc-cs!phillips
  3. From: phillips@cs.ubc.ca (George Phillips)
  4. Subject: Re: die hook
  5. Message-ID: <1992Aug27.052530.11544@cs.ubc.ca>
  6. Sender: usenet@cs.ubc.ca (Usenet News)
  7. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  8. References: <Aug.13.17.56.21.1992.22441@piecomputer.rutgers.edu> <1992Aug15.030457.21382@netlabs.com>
  9. Date: Thu, 27 Aug 92 05:25:30 GMT
  10. Lines: 30
  11.  
  12. In article <1992Aug15.030457.21382@netlabs.com> lwall@netlabs.com (Larry Wall) writes:
  13. >The code I'm developing for Perl 5 already has two magical subroutines
  14. >in it called BEGIN and END.  They're so magical that you don't even have
  15. >to put "sub" in front of them.  BEGIN is automatically called before
  16. >the program starts, and END is automatically called just before the
  17. >program exits, no matter how it exits.
  18.  
  19. Do you get a magical BEGIN and END for each package or just one set for
  20. the entire program?  Seems like it would be a great way for required
  21. subroutine modules to install cleanup routines without extra bookkeeping
  22. on the part of the main program.  The BEGIN subroutine may be a problem
  23. since the earliest it could run would be at require time, but then
  24. again required files already have BEGIN.
  25.  
  26. I guess you could make non-lazy programmers write out their ENDing
  27. sequence explicitly:
  28.  
  29.     END {
  30.         &foo'END;
  31.         &bar'END;
  32.         print "Bye!\n";
  33.     }
  34.  
  35. But that means that some day you'll forget to add an END call when
  36. you do a require.  I think it would be better to call each package's
  37. END in reverse order of initial definition of each package (which
  38. guarantees main'END would be last, right?).  You might be upset
  39. that the main program cannot decide for itself if a module should
  40. be shut down, but it's only fair to assume that if a module needs
  41. to prepare for death it has good reasons for doing so.
  42.