Programming Perl: Unmatched Power for Text Processing and Scripting by Tom Christiansen, brian d foy, Larry Wall, Jon Orwant |, Paperback | Barnes & Noble
Programming Perl: Unmatched Power for Text Processing and Scripting

Programming Perl: Unmatched Power for Text Processing and Scripting

5.0 1
by Tom Christiansen, brian d foy, Larry Wall, Jon Orwant
     
 

View All Available Formats & Editions

Adopted as the undisputed Perl bible soon after the first edition appeared in 1991, Programming Perl is still the go-to guide for this highly practical language. Perl began life as a super-fueled text processing utility, but quickly evolved into a general purpose programming language that’s helped hundreds of thousands of programmers, system

Overview

Adopted as the undisputed Perl bible soon after the first edition appeared in 1991, Programming Perl is still the go-to guide for this highly practical language. Perl began life as a super-fueled text processing utility, but quickly evolved into a general purpose programming language that’s helped hundreds of thousands of programmers, system administrators, and enthusiasts, like you, get your job done.

In this much-anticipated update to "the Camel," three renowned Perl authors cover the language up to its current version, Perl 5.14, with a preview of features in the upcoming 5.16. In a world where Unicode is increasingly essential for text processing, Perl offers the best and least painful support of any major language, smoothly integrating Unicode everywhere—including in Perl’s most popular feature: regular expressions.

Important features covered by this update include:

  • New keywords and syntax
  • I/O layers and encodings
  • New backslash escapes
  • Unicode 6.0
  • Unicode grapheme clusters and properties
  • Named captures in regexes
  • Recursive and grammatical patterns
  • Expanded coverage of CPAN
  • Current best practices

Editorial Reviews


Fatbrain Review

The definitive Perl 5 reference and user's guide, from the creator of Perl. An extensive overview is followed by details of syntax, terms, operators, pattern matching, formats, variables, and functions. Discusses references and nested data structures, packages, modules, object classes, social engineering (cooperation with other processes and languages), and, of course, the Standard Perl Library. For programmers unsure of their scripting prowess, we suggest two good companion volumes for this reference: Perl 5 Interactive Course by Orwant and Perl 5 How-To by Glover et al. The first is a comprehensive Perl tutorial, complete with your ezone mentor on the Web. The second is a practical guide, complete with problem solving scripting examples and excellent debugging and diagnostic procedures for this Pathologically Eclectic Rubbish Lister (aka Perl).
Donald Bryson

TMTOWTDI (There's More Than One Way To Do It)

How do you write the canon for a programming language that you created? Some writers will spend much of the reader's time trying to prove that their language is naturally superior because it was conceived by their superior mind. They are the ones that sprinkle their books with phrases like "as you can clearly see" as a preamble for ideas only understood by green-blooded science officers that say goodbye with "live long and prosper." Even among the humble, most write a reference book with the warmth of a logarithmic chart and the pathos of a decision table. But, in keeping with the Perl philosophy of TMTOWTDI, Wall shows us a more excellent way.

Programming Perl has warmth, personality, and, at unexpected times, brilliant wit. It feels like a explanation from a close friend. It even has a short section on Perl poetry.

How warm is it? Perl is the only language with an officially sanctioned thingy. A thingy, as defined by the authors, is "a value that is sort of like an object, that you may or may not know the name of, but that you can refer to via references from which the thingy dangles, metaphorically speaking." I don't feel quite so guilty now for checking the do-lollies in my C code by setting the warning level to puke-on-all.

Programming Perl is not an easy introduction to the language. This is especially true for the UNIX-challenged. The authors casually assume you know about things (or should I say thingies) like character block devices, UNIX-file permissions, and utmp files. If you expect a C> prompt when you sit down in front of a SUN -- start with a different book. Also, Programming Perl, like the language, is very dense. Complex ideas are compressed into the shortest space possible. What else would you expect from the folks that brought you the elusive and oft unseen $_ variable? If you are new to Perl and inherited a web site with Perl CGI scripts that must be changed by next Monday, try Learning Perl by Randal Schwartz instead.

While Programming Perl is not a good introduction, it is the definitive reference of the language. It is the one required book for all Perl programmers. It is the original source for syntax, semantics, and core functionality. It is the Perl version of The C Programming Language by Kernighan and Ritchie. It's the same thing, only funnier.--Dr. Dobb's Electronic Review of Computer Books

Product Details

ISBN-13:
9780596004927
Publisher:
O'Reilly Media, Incorporated
Publication date:
03/05/2012
Edition description:
Fourth Edition
Pages:
1184
Sales rank:
459,432
Product dimensions:
7.00(w) x 9.20(h) x 2.30(d)

Read an Excerpt


Chapter 5: Packages, Modules, and Object Classes

...Within the class package, methods will typically deal with the reference as an ordinary (unblessed) reference to a thingy. Outside the class package, the reference should generally be treated as an opaque value that may only be accessed through the class's methods. (Mutually consenting classes may of course do whatever they like with each other, but even that doesn't necessarily make it right.)

A constructor may re-bless a referenced object currently belonging to another class, but then the new class is responsible for all cleanup later. The previous blessing is forgotten, as an object may only belong to one class at a time. (Although of course it's free to inherit methods from many classes.)

A clarification: Perl objects are blessed. References are not. Thingies know which package they belong to. References do not. The bless operator simply uses the reference in order to find the thingy. Consider the following example:

$a = {}; # generate reference to hash
$b = $a; # reference assignment (shallow)
bless $b, Mountain;
bless $a, Fourteener;
print "\$b is a ", ref ($b), "\n";

This reports $b as being a member of class Fourteener, not a member of class Mountain, because the second blessing operates on the underlying thingy that $a refers to, not on the reference itself. Thus is the first blessing forgotten.

A Class Is Simply a Package

Perl doesn't provide any special syntax for class definitions. You just use a package as a class by putting method definitions into the class.

Within each package a special array called @ISA tells Perlwhere else to look for a method if it can't find the method in that package. This is how Perl implements inheritance. Each element of the @ISA array is just the name of another package that happens to be used as a class. The packages are recursively searched (depth first) for missing methods, in the order that packages are mentioned in @ISA. This means that if you have two different packages (say, Mom and Dad) in a class's @ISA, Perl would first look for missing methods in Mom and all of her ancestor classes before going on to search through Dad and his ancestors. Classes accessible through @ISA are known as bare classes of the current class, which is itself called the derived class.

If a missing method is found in one of the base classes, Perl internally caches that location in the current class for efficiency, so the next time it has to find the method, it doesn't have to look so far. Changing @ISA or defining new subroutines invalidates this cache and causes Perl to do the lookup again.

If a method isn't found but an AUTOLOAD routine is found, then that routine is called on behalf of the missing method, with that package's $AUTOLOAD variable set to the fully qualified method name.

If neither a method nor an AUTOLOAD routine is found in @ISA, then one last, desperate try is made for the method (or an AUTOLOAD routine) in the special predefined class called UNIVERSAL. This package does not initially contain any definitions (although see CPAN for some), but you may place your "last-ditch" methods there. Think of it as a global base class from which all other classes implicitly derive.

If that method still doesn't work, Perl finally gives up and complains by raising an exception.

Perl classes do only method inheritance. Data inheritance is left up to the class itself. By and large, this is not a problem in Perl, because most classes model the attributes of their object using an anonymous hash. All the object's data fields (termed "instance variables" in some languages) are contained within this anonymous hash instead of being part of the language itself. This hash serves as its own little namespace to be carved up by the various classes that might want to do something with the object. For example, if you want an object called $user_info to have a data field named age, you can simply access $user_info->{age}. No declarations are necessary. See the section on "Instance Variables" under "Some Hints About Object Design" later in this chapter.

A Method Is Simply a Subroutine

Perl doesn't provide any special syntax for method definition. (It does provide a little syntax for method invocation, though. More on that later.) A method expects its first argument to indicate the object or package it is being invoked on.

Class methods

a class method expects a class (package) name as its first argument. (The class name isn't blessed; it's just a string.) These methods provide functionality for the class as a whole, not for any individual object instance belonging to the class. Constructors are typically written as class methods, Many class methods simply ignore their first argument, since they already know what package they're in, and don't care what package they were invoked via. (These aren't necessarily the same, since class methods follow the inheritance tree just like ordinary instance methods.)...

Meet the Author

Tom Christiansen is a freelance consultant specializing in Perl training and writing. After working for several years for TSR Hobbies (of Dungeons and Dragons fame), he set off for college where he spent a year in Spain and five in America, dabbling in music, linguistics, programming, and some half-dozen differentspoken languages. Tom finally escaped UW-Madison with undergraduate degrees in Spanish and computer science and a graduate degree in computer science. He then spent five years at Convex as a jack-of-all-trades working on everything from system administration to utility and kernel development, withcustomer support and training thrown in for good measure. Tom also served two terms on the USENIX Association Board of directors. With over thirty years' experience in Unix systems programming, Tom presents seminars internationally. Living in the foothills above Boulder, Colorado, Tom takes summers off for hiking, hacking, birding, music making, and gaming.

brian d foy is a prolific Perl trainer and writer, and runs The Perl Review to help people use and understand Perl through educational, consulting, code review, and more. He's a frequent speaker at Perl conferences. He's the coauthor of Learning Perl, Intermediate Perl, and Effective Perl Programming, and the author of Mastering Perl. He was an instructor and author for Stonehenge Consulting Services from 1998 to 2009, a Perl user since he was a physics graduate student, and a die-hard Mac user since he first owned a computer. He founded the first Perl user group, the New York Perl Mongers, as well as the Perl advocacy nonprofit Perl Mongers, Inc., which helped form more than 200 Perl user groups across the globe. He maintains the perlfaq portions of the core Perl documentation, several modules on CPAN, and some standalone scripts.

Larry Wall originally created Perl while a programmer at Unisys. He now works full time guiding the future development of the language. Larry is known for his idiosyncratic and thought-provoking approach to programming, as well as for his groundbreaking contributions to the culture of free software programming.

Jon Orwant founded The Perl Journal and received the White Camel lifetime achievement award for contributions to Perl in 2004. He's Engineering Manager at Google, where he leads Patent Search, visualizations, and digital humanities teams. For most of his tenure at Google, Jon worked on Book Search, and he developed the widely used Google Books Ngram Viewer. Prior to Google, he wasCTO of O'Reilly, Director of Research at France Telecom, and a Lecturer at MIT. Orwant received his doctorate from MIT's Electronic Publishing Group in 1999.

Customer Reviews

Average Review:

Write a Review

and post it to your social network

     

Most Helpful Customer Reviews

See all customer reviews >