Advanced Perl Programming - csbdu.in

1 ;-_=_Scrolldown to the Underground_=_-; Advanced perl Sriram Srinivasan; ISBN 1-56592-220-4, 434 Edition, August 1997.(See the catalog page for this book.)Search the text of Advanced perl | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | ZTable of ContentsPrefaceChapter 1: Data References and Anonymous StorageChapter 2: Implementing Complex Data StructuresChapter 3: Typeglobs and Symbol TablesChapter 4: Subroutine References and ClosuresChapter 5: EvalChapter 6: ModulesChapter 7: Object-Oriented ProgrammingChapter 8: Object Orientation: The Next Few StepsChapter 9: TieChapter 10: PersistenceChapter 11.

2 Implementing Object PersistenceChapter 12: Networking with SocketsChapter 13: Networking: Implementing RPCC hapter 14: User Interfaces with TkChapter 15: GUI Example: TetrisChapter 16: GUI Example: Man Page ViewerChapter 17: Template-Driven Code GenerationChapter 18: Extending perl :A First CourseChapter 19: Embedding perl :The Easy WayChapter 20: perl InternalsAppendix A: Tk Widget ReferenceAppendix B: Syntax SummaryExamplesThe perl CD BookshelfNavigationCopyright 1999 O'Reilly & Associates. All Rights Reserved.

3 PrefaceNext: WhyPerl? PrefaceContents:The Case for ScriptingWhy perl ?What Must I Know?The Book's ApproachConventionsResourcesPerl ResourcesWe'd Like to Hear from YouAcknowledgmentsErrors, like straws, upon the surface flow;He who would search for pearls must dive John Dryden, All for Love, PrologueThis book has two goals: to make you a perl expert, and, at a broader level, to supplement your currentarsenal of techniques and tools for crafting applications. It covers Advanced features of the perl language,teaches you how the perl interpreter works, and presents areas of modern computing technology such asnetworking, user interfaces, persistence, and code will not merely dabble with language syntax or the APIs of different modules as you read this will spend just as much time dealing with real-world issues such as avoiding deadlocks duringremote procedure calls and switching smoothly between data storage using a flat file or a the way.

4 You'll become comfortable with such perl techniques as run-time evaluation, nested datastructures, objects, and book expects you to know the essentials of perl - a minimal subset, actually; you must beconversant with the basic data types (scalars, arrays, and hashes), regular expressions, subroutines, basiccontrol structures (if, while, unless, for, foreach), file I/O, and standard variables such as@ARGV and $_. Should this not be the case, I recommend Randal Schwartz and Tom Christiansen'sexcellent tutorial, Learning perl , Second book - in particular, this preface - substantiates two convictions of first is that a two-language approach is most appropriate for tackling typical large-applicationprojects: a scripting language (such as perl , Visual Basic, Python, or Tcl) in conjunction with a systemsprogramming language (C, C++, Java).

5 A scripting language has weak compile-time type checking, hashigh-level data structures (for instance, perl 's hash table is a fundamental type; C has no such thing), anddoes not typically have a separate compilation-linking phase. A systems Programming language istypically closer to the operating system, has fine-grained data types (C has short, int, long, unsigned int,float, double, and so on, whereas perl has a scalar data type), and is typically faster than interpretedlanguages. perl spans the language spectrum to a considerable degree: It performs extremely well as ascripting language, yet gives you low-level access to operating system API, is much faster than Java (asthis book goes to press), and can optionally be distinction between scripting and systems Programming languages is a contentious one, but it hasserved me well in practice.

6 This point will be underscored in the last three chapters of the book (onextending perl , embedding perl , and perl internals).I believe that neither type of language is properly equipped to handle sophisticated application projectssatisfactorily on its own, and I hope to make the case for perl and C/C++ as the two-languagecombination mentioned earlier. Of course, it would be most gratifying, or totally tubular, as the localkids are wont to say, if the design patterns and lessons learned in this book help you even if you were tochoose other second conviction of mine is that to deploy effective applications, it is not enough just to know thelanguage syntax well.

7 You must know, in addition, the internals of the language's environment, and youmust have a solid command of technology areas such as networking, user interfaces, databases, and soforth (specially issues that transcend language-specific libraries).Let's look at these two points in greater Case for ScriptingI started my professional life building entire applications in assembler, on occasion worrying about tryingto save 100 bytes of space and optimizing away that one extra instruction. C and PL/M changed myworld view.

8 I found myself getting a chance to reflect on the application as a whole, on the life-cycle ofthe project, and on how it was being used by the end-user. Still, where efficiency was paramount, as wasthe case for interrupt service routines, I continued with assembler. (Looking back, I suspect that thePL/M compiler could generate far better assembly code than I, but my vanity would have prevented suchan admission.)My applications' requirements continued to increase in complexity; in addition to dealing with graphicaluser interfaces, transactions, security, network transparency, and heterogeneous platforms, I began to getinvolved in designing software architectures for problems such as aircraft scheduling and networkmanagement.

9 My own efficiency had become a much more limiting factor than that of the object orientation was making me more effective at the design level, the implementation language,C++, and the libraries and tools available weren't helping me raise my level of Programming . I was stilldealing with low-level issues such as constructing frameworks for dynamic arrays, meta-data, textmanipulation, and memory management. Unfortunately, environments such as Eiffel, Smalltalk, and theNeXT system that dealt with these issues effectively were never a very practical choice for myorganization.

10 You might understand why I have now become a raucous cheerleader for Java as theapplication development language of choice. The story doesn't end there, , the realization has slowly crept up on me that I have been ignoring two big time-sinks at eitherend of a software life-cycle. At the designing end, sometimes the only way to clearly understand theproblem is to create an electronic storyboard (prototype). And later, once the software is implemented,users are always persnickety (er, discerning) about everything they can see, which means that evensimple form-based interfaces are constantly tweaked and new types of reports are constantly , of course, the sharper developers wish to move on to the next project as soon as the software isimplemented.