📄 ch10_01.htm
字号:
<html><head><title>Packages (Programming Perl)</title><!-- STYLESHEET --><link rel="stylesheet" type="text/css" href="../style/style1.css"><!-- METADATA --><!--Dublin Core Metadata--><meta name="DC.Creator" content=""><meta name="DC.Date" content=""><meta name="DC.Format" content="text/xml" scheme="MIME"><meta name="DC.Generator" content="XSLT stylesheet, xt by James Clark"><meta name="DC.Identifier" content=""><meta name="DC.Language" content="en-US"><meta name="DC.Publisher" content="O'Reilly & Associates, Inc."><meta name="DC.Source" content="" scheme="ISBN"><meta name="DC.Subject.Keyword" content=""><meta name="DC.Title" content="Packages"><meta name="DC.Type" content="Text.Monograph"></head><body><!-- START OF BODY --><!-- TOP BANNER --><img src="gifs/smbanner.gif" usemap="#banner-map" border="0" alt="Book Home"><map name="banner-map"><AREA SHAPE="RECT" COORDS="0,0,466,71" HREF="index.htm" ALT="Programming Perl"><AREA SHAPE="RECT" COORDS="467,0,514,18" HREF="jobjects/fsearch.htm" ALT="Search this book"></map><!-- TOP NAV BAR --><div class="navbar"><table width="515" border="0"><tr><td align="left" valign="top" width="172"><a href="ch09_07.htm"><img src="../gifs/txtpreva.gif" alt="Previous" border="0"></a></td><td align="center" valign="top" width="171"><a href="part2.htm">Part 2: The Gory Details</a></td><td align="right" valign="top" width="172"><a href="ch10_02.htm"><img src="../gifs/txtnexta.gif" alt="Next" border="0"></a></td></tr></table></div><hr width="515" align="left"><!-- SECTION BODY --><h1 class="chapter">Chapter 10. Packages</h1><div class="htmltoc"><h4 class="tochead">Contents:</h4><p><a href="ch10_01.htm">Symbol Tables</a><br><a href="ch10_02.htm">Autoloading</a><br></p></div><p><a name="INDEX-2178"></a>In this chapter, we get to start having fun, because we get to starttalking about software design. If we're going to talk about goodsoftware design, we have to talk about Laziness, Impatience, andHubris, the basis of good software design.</p><p><a name="INDEX-2179"></a>We've all fallen into the trap of using cut-and-paste when we shouldhave defined a higher-level abstraction, if only just a loop orsubroutine.<a href="#FOOTNOTE-1">[1]</a> To be sure, some folks have gone to theopposite extreme of defining ever-growing mounds of higher-levelabstractions when they should have used cut-and-paste.<a href="#FOOTNOTE-2">[2]</a> Generally, though,most of us need to think about using more abstraction rather thanless.</p><blockquote class="footnote"><a name="FOOTNOTE-1"></a><p>[1] This is a form of FalseLaziness.</p></blockquote><blockquote class="footnote"><a name="FOOTNOTE-2"></a><p>[2]This is a form of False Hubris.</p></blockquote><p>Caught somewhere in the middle are the people who have a balanced viewof how much abstraction is good, but who jump the gun on writing theirown abstractions when they should be reusing existingcode.<a href="#FOOTNOTE-3">[3]</a></p><blockquote class="footnote"><a name="FOOTNOTE-3"></a><p>[3] You guessed it--this is False Impatience.But if you're determined to reinvent the wheel, at least try to inventa better one.</p></blockquote><p>Whenever you're tempted to do any of these things, you need to sitback and think about what will do the most good for you and yourneighbor over the long haul. If you're going to pour your creativeenergies into a lump of code, why not make the world a better placewhile you're at it? (Even if you're only aiming for the program to<em class="emphasis">succeed</em>, you need to make sure it fits the rightecological niche.)</p><p><a name="INDEX-2180"></a>The first step toward ecologically sustainable programming is simply this:don't litter in the park. When you write a chunk of code, think aboutgiving the code its own namespace, so that your variables and functionsdon't clobber anyone else's, or vice versa. A namespace is a bit likeyour home, where you're allowed to be as messy as you like, as long asyou keep your external interface to other citizens moderately civil. InPerl, a namespace is called a <em class="emphasis">package</em>. Packages provide thefundamental building block upon which the higher-level concepts ofmodules and classes are constructed.</p><p><a name="INDEX-2181"></a><a name="INDEX-2182"></a><a name="INDEX-2183"></a><a name="INDEX-2184"></a>Like the notion of "home", the notion of "package" is a bit nebulous.Packages are independent of files. You can have many packages in asingle file, or a single package that spans several files, just asyour home could be one small garret in a larger building (if you're astarving artist), or it could comprise several buildings (if your name happensto be Queen Elizabeth). But the usual size of a home is one building,and the usual size of a package is one file. Perl provides somespecial help for people who want to put one package in one file, aslong as you're willing to give the file the same name as the packageand use an extension of <em class="emphasis">.pm</em>, which is short for "perlmodule". The <em class="emphasis">module</em> is the fundamental unit of reusability in Perl.Indeed, the way you use a module is with the <tt class="literal">use</tt> command, which isa compiler directive that controls the importation of subroutines andvariables from a module. Every example of <tt class="literal">use</tt> you've seen untilnow has been an example of module reuse.<a name="INDEX-2185"></a></p><p><a name="INDEX-2186"></a><a name="INDEX-2187"></a><a name="INDEX-2188"></a> The Comprehensive PerlArchive Network, or CPAN, is where you should put your modules ifother people might find them useful. Perl has thrived because of thewillingness of programmers to share the fruits of their labor with thecommunity. Naturally, CPAN is also where you can find modules thatothers have thoughtfully uploaded for everyone to use. See <a href="ch22_01.htm">Chapter 22, "CPAN"</a>, and www.cpan.org fordetails.</p><p><a name="INDEX-2189"></a><a name="INDEX-2190"></a>The trend over the last 25 years or so has been to design computerlanguages that enforce a state of paranoia. You're expected toprogram every module as if it were in a state of siege. Certainlythere are some feudal cultures where this is appropriate, but not allcultures are like this. In Perl culture, for instance, you'reexpected to stay out of someone's home because you weren't invited in,not because there are bars on the windows.<a href="#FOOTNOTE-4">[4]</a></p><blockquote class="footnote"><a name="FOOTNOTE-4"></a><p>[4] But Perlprovides some bars if you want them, too. See "Handling InsecureCode" in <a href="ch23_01.htm">Chapter 23, "Security"</a>.</p></blockquote><p><a name="INDEX-2191"></a>This is not a book about object-oriented methodology, and we're nothere to convert you into a raving object-oriented zealot, even if youwant to be converted. There are already plenty of books out there forthat. Perl's philosophy of object-oriented design fits right in withPerl's philosophy of everything else: use object-oriented design whereit makes sense, and avoid it where it doesn't. Your call.</p><p><a name="INDEX-2192"></a><a name="INDEX-2193"></a>In OO-speak, every object belongs to a grouping called a <em class="emphasis">class</em>. InPerl, classes and packages and modules are all so closely related thatnovices can often think of them as being interchangeable. The typicalclass is implemented by a module that defines a package with thesame name as the class. We'll explain all of this in the next few chapters.</p><p><a name="INDEX-2194"></a>When you <tt class="literal">use</tt> a module, you benefit from direct software reuse.With classes, you benefit from indirect software reuse when one classuses another through inheritance. And with classes, you get somethingmore: a clean interface to another namespace. Everything in a classis accessed indirectly, insulating the class from the outside world.</p><p>As we mentioned in <a href="ch08_01.htm">Chapter 8, "References"</a>, object-oriented programmingin Perl is accomplished through references whose referents know which class they belong to. In fact, now that you know aboutreferences, you know almost everything difficult about objects. The restof it just "lays under the fingers", as a pianist would say. Youwill need to practice a little, though.<a name="INDEX-2195"></a><a name="INDEX-2196"></a></p><p><a name="INDEX-2197"></a><a name="INDEX-2198"></a><a name="INDEX-2199"></a><a name="INDEX-2200"></a>One of your basic finger exercises consists of learning how to protectdifferent chunks of code from inadvertently tampering with eachother's variables. Every chunk of code belongs to a particular<em class="emphasis">package</em>, which determines what variables andsubroutines are available to it. As Perl encounters a chunk of code,it is compiled into what we call the <em class="emphasis">currentpackage</em>. The initial current package is called"<tt class="literal">main</tt>", but you can switch the current package toanother one at any time with the <tt class="literal">package</tt>declaration. The current package determines which symbol table isused to find your variables, subroutines, I/O handles, and formats.<a name="INDEX-2201"></a></p><p><a name="INDEX-2202"></a>Any variable not declared with <tt class="literal">my</tt> is associatedwith a package--even seemingly omnipresent variables like<tt class="literal">$_</tt> and <tt class="literal">%SIG</tt>. In fact, there'sreally no such thing as a global variable in Perl, just package⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -