Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Books PHP Programming Book Reviews

Book Review: Programming PHP 3rd Edition 155

Michael Ross writes "As a hugely popular scripting language with an 18-year history, PHP has been the topic of countless computer language books. One of the most comprehensive offerings has been Programming PHP, published by O'Reilly Media. The first edition appeared in March 2002, and was written by Rasmus Lerdorf (the original developer of PHP) and Kevin Tatroe. A second edition was released in May 2006, and saw the addition of another co-author, Peter MacIntyre. With the many changes to the language during the past seven years, the book has again been updated, to cover all of the major new features made available in version 5 of PHP." Keep reading for the rest of Michael's review.
Programming PHP, 3rd Edition
author Kevin Tatroe, Peter MacIntyre and Rasmus Lerdorf
pages 540
publisher O'Reilly Media
rating 8/10
reviewer Michael Ross
ISBN 978-1449392772
summary An extensive tutorial of the PHP web programming language.
This third edition was published on 22 February 2013, under the ISBN 978-1449392772, with the same three authors at the helm. At a substantial 540 pages, the information is organized into 17 chapters, each focusing on a particular area of the language and its usage. This material precedes an appendix of almost 130 pages, which serves as a reference for all of the language's built-in functions. In fact, not only could this book suffice as a reference guide, it could also serve as a tutorial, because it is accessible to programmers of all levels, including beginners who have never before worked with PHP. The preface notes that the material assumes only "a working knowledge of HTML." However, the example code seems to also assume that the reader is comfortable with fundamental programming concepts, such as conditionals and loops.

To learn more about the book, prospective readers and buyers may wish to visit the publisher's website, where they will find a description of the book, its table of contents, a free copy of its first chapter, and the example code for ten of the chapters. Speaking of formats, the book is available in print and electronic media. (This review is based upon a copy of the print version kindly provided by the publisher.)

The first three chapters explain the bedrock fundamentals of the language, including its lexical structure, data types, variables, expressions, operators, flow-control statements, code inclusion methods, and functions. All of the information appears to be valid, aside from several technical blemishes: In Example 1-1, most of the lines of code are duplicated. Example 1-5, which supposedly creates a PNG file, does not seem to work. The section on constants (page 21) should have mentioned the core predefined constants and also distinguished those from magic ones. The binary literal 0b01100000 is 96, not 1 (page 23). It is claimed that an object is evaluated as false if it contains no values or functions (page 25), and yet: "class C{} assert( new C );." The closure example code (page 29) fails because it includes a function name and no terminating semicolon. The example code in the middle of page 66 contradicts the claim that an inner function "cannot be called from code parsed after the outer function." The example code starting at the end of that page fails because $a in foo() is undefined. Nonetheless, even experienced PHP programmers could pick up knowledge not encountered before, or at least refresh what was learned years ago and since forgotten due to disuse.

The next two chapters explore in detail further essential components of PHP: strings, regular expressions, and arrays. As with the earlier chapters, readers will encounter example code that does not appear to have been tested. For instance, the print_r() output of an object is missing the class name (page 84). On the same page, print_r() and var_dump() of $GLOBALS do indicate "*RECURSION*," but do not loop infinitely or three times, respectively, as claimed. The $record on page 86 is missing its trailing tab character. For these errors and others, it is not clear whether the authors or the technical reviewers are ultimately responsible. Regardless, readers should find useful the tables summarizing regular expression character classes, anchors, quantifiers, and options. On the other hand, the treatment of conditional expressions is sorely in need of examples. Also, readers will be baffled when told that "The preg_match() function takes the same arguments and gives the same return value as the preg_match() function []" (page 112). Lastly, the callback example code is faulty (pages 131, 133, and 141). The sixth chapter, covering object-oriented programming is well-written, aside from the confusing phrase "including it to a different name" (page 160) and the anti-Nietzschean "this will fatal" (page 161).

With Chapter 7, the book shifts gears from the basic underpinnings of PHP to more applied topics, in this case, web techniques — specifically HTTP, global variables, server information, web form processing, sessions, and more. The narrative is quite clear, except when the reader is told that periods in field names are converted to underscores because periods are illegal in PHP variable names (page 178); the connection is not explained. The next chapter looks at server-side data storage, including the topics of PDO, MySQLi, SQLite, and MongoDB. Confusingly, readers are told that the sample SQL database code is available in a file, but they are not told where to find it (http://examples.oreilly.com/0636920012443/).

Chapters 9 through 11 address PHP's support for three specialized file types: graphics, PDF, and XML. The explanations are excellent, and the authors provide numerous examples. The only obvious flaws are in Example 11-1 (page 269), where the echo statement is missing the "<?" and two of the lines have mismatched single and double quotes.

The remaining half dozen chapters cover critical aspects of PHP development. The chapter on security does not attempt to be exhaustive, but instead explains the most common attack vectors and how to block them. The chapter on application techniques discusses code libraries, templating, output buffering and compression, error handling, and performance tuning. Any programmer intrigued by the idea of replacing clunky VBA code with PHP, should be interested in Chapter 14, which explores the differences in running PHP on Windows vs. other platforms, with a brief look at manipulating the contents of Microsoft Word and Excel files using PHP. RESTful web services and XML-RPC are the topics of the next chapter, whose only apparent blemish is that json_encode() does not add spaces between the array values (page 339). The penultimate chapter addresses multiple environments, manual debugging, and the use of an IDE. The last chapter briefly covers PHP support for dates and times, and thus should have been located much earlier in the book, with the other material on fundamental concepts.

Overall, this book is quite approachable. Throughout, one will find programming style recommendations, However, as with any technical work of this size, there are passages that could be made more complete or clear. Occasionally the authors will mention something explained only later — e.g., "short echo tag" (page 60) — which can be frustrating to anyone new to a language.

The concepts of PHP being taught are extensively illustrated with example code. Some of it is concise enough so as not to distract from the narrative flow, but far too many examples involve much more code than necessary. This at first glance might seem to be an advantage, but it actually makes it more difficult for the reader to see the parts of the code relevant to the topic at hand. Also, the authors underutilize whitespace in the code, instead jamming tokens and parentheses together.

In a book of this size, we should not be astonished to find some errata: "Wordpress" (page xv), "try and" (same page; should read "try to"), "tick function registered when register_tick_function()" (55; should read "with" not "when"), "eXtensible" (59), "super-global" (67; should read "superglobal"), "display_classes() function" (vs. "function displayClasses()"; 164), "$var" (294 and 295; should read "$value"), "functions of blocks" (323; should read "functions or blocks"), "retried" (337; should read "retrieved"), and "a.k.a." (350; should read "e.g.").

In terms of the production of the book, like most other O'Reilly titles, this one is nicely put together, with readable font. But sometimes words are jammed together so much that lines appear to be a single word, e.g., "codeitselfbutplentifulenoughthatyoucanusethecommentstotellwhat'shappening" (page 17). Also, the publisher should avoid splitting the function names as if they were English words, e.g., "addc" and "slashes()" on separate lines (page 91). The index is missing some obvious entries, e.g., "closures." Many code snippets are missing the "Example" numbers and captions. This may be fine if the authors do not reference those snippets, but makes it problematic for anyone else to reference them.

Even though this is arguably one of the most comprehensive PHP books on the market, it does not cover all aspects of the language. On page 1, readers learn that PHP can be utilized in three major ways — server-side scripting, command-line scripting, and client-side GUI applications; but only the first is covered in the book. The appendix consumes over 120 pages, and comprises information easily available online in the PHP manual's function reference. Those pages could instead have been devoted to at least introducing command-line scripting and GUI applications. In fact, there are two major changes the authors could take in bringing this book much closer to perfection: Firstly, retest all of the code and root out any technical snafus. Secondly, replace the lengthy appendix with full coverage of the topics of command-line scripting and client-side GUI applications.

Regardless, Programming PHP is both a tutorial and a reference resource packed with information and example code. Benefiting from the author's deep expertise in the language and its usage, the book is the most promising single source for anyone who wishes to learn this ubiquitous web scripting language.

Michael Ross is a freelance web developer and writer.

You can purchase Programming PHP, 3rd Edition from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Book Review: Programming PHP 3rd Edition

Comments Filter:
  • But... (Score:3, Funny)

    by stewsters ( 1406737 ) on Monday July 08, 2013 @02:56PM (#44218593)
    I stopped after i read about GOTO [php.net]. Do you want raptors?
    • Re: (Score:3, Insightful)

      by KalvinB ( 205500 )

      Even the manual acknowledges it is bad practice and includes the XKCD comic

      There are so many languages that try to hide bad programmers. Give me a PHP programmer and his code and I can tell you if he's worth anything, The language lets you code like an idiot. Which is great, because then I can either not hire you or pay you accordingly if I think you have potential.

      GOTO is not a part of PHP so you can use it. It's part of PHP so that if you use it, you are immediately fired and blackballed from the indu

      • by ackthpt ( 218170 )

        Even the manual acknowledges it is bad practice and includes the XKCD comic

        There are so many languages that try to hide bad programmers. Give me a PHP programmer and his code and I can tell you if he's worth anything, The language lets you code like an idiot. Which is great, because then I can either not hire you or pay you accordingly if I think you have potential.

        GOTO is not a part of PHP so you can use it. It's part of PHP so that if you use it, you are immediately fired and blackballed from the industry. It's a trap.

        I did encounter a piece of code, ages ago, where in a GOTO was the only possible way to accomplish something. They're pretty rare, but in the instance you need the option it is nice knowing it is there.

        • by Anonymous Coward
          I would actually like to see that code. I don't think it is the only way, but if it was that would be cool. If you ever see it again, post it here.
          • Re:But... (Score:5, Informative)

            by vilanye ( 1906708 ) on Monday July 08, 2013 @04:07PM (#44219217)
            The linux kernel has many examples. A common usage is using goto to deal with exceptions so you don't fill up the critical path with branches and blow your cache.

            Some newbie actually went on the kernel's mailing list a long time ago, shocked that GOTO's existed and proposed all sorts of lamebrained approaches just to avoid a clean usage of GOTO like this(shamelessly stolen from one of Robert Love's responses):

            do A
            if (error)
            goto out_a;
            do B
            if (error)
            goto out_b;
            do C
            if (error)
            goto out_c;
            goto out;
            out_c:
            undo C
            out_b:
            undo B:
            out_a:
            undo A
            out:
            return ret;

            Easy to read, provides clean stack unwinding, avoids blowing out your cache and only branches on error conditions.

            Linus was actually nice to this kid, which surprised me because he deserved all the vitriol he got and more.

            One the other hand, that a newbie was actually reading Linux source code was pretty amazing to me. But going on the mailing list and chastising experienced kernel programmers was pretty funny.

            Djikstra never gave his paper the title "GOTO's considered harmful", I think it was Wirth acting as editor and who is someone you can ignore safely.

            His paper was talking about GOTO's that can bounce all over the place, something essentially impossible in C where GOTO's are local in the function(ignoring longjmp). The paper was published several years before C was developed making his paper irrelevant to C style GOTO's.

            I think I used GOTO once, in a virtual machine project that ran bytecode for a educational language that teaches parallel programming concepts.

        • I don't think "the only possible way" means what you think it does.
          • Then, "the only way to accomplish something without avoiding goto with lamebrained alternatives just for the sake of avoiding goto"

            • By "lamebrained" read "actually knows how to code".

              Name JUST ONE circumstance where using a Goto in a higher level language isn't the wrong choice.

              Just one.

            • the only way to accomplish something without avoiding goto with lamebrained alternatives just for the sake of avoiding goto

              You may as well omit that long-ass conditional and just say "the simplest way to accomplish something."

        • Re:But... (Score:5, Insightful)

          by narcc ( 412956 ) on Monday July 08, 2013 @04:00PM (#44219153) Journal

          Indeed. GOTO is not inherently evil. You'll find it used appropriately in some surprising places -- including the Linux Kernel [oracle.com].

          When describing a process, the oft-maligned GOTO certainly comes in handy. The over 30 crowd might remember seeing GOTO's in any number of guide books from auto repair to taxes. (The word wasn't always used, sometimes "skip to ..." or "continue with ..." etc.)

          That's right: GOTO can actually make things easier to read and understand.

          Even in software today, I'm willing to bet even the most ardent anti-GOT zealot has used a GOTO -- and recently at that -- cleverly disguised as a break or return statement.

        • by jon3k ( 691256 )
          There's absolutely no way it was "the only possible way of accomplishing something"
        • There is no circumstance where a Goto is the "only possible way". I've been coding for 20+ years, and the last time I used a goto was when as a teenager I graduated from BASIC to Pascal.

          Literally, computer science style, *all* possible uses with one exception can be replaced.

          And that one exception will never occur in PHP code, as its related to system level assembly programming where the CPUs jump-with-return instructions are not appropriate to the task at hand.

      • by fisted ( 2295862 )
        > Give me a PHP programmer and I can tell you he isn't worth anything
        FTFY
        • > Give me a PHP programmer and I can tell you he isn't worth anything

          FTFY

          Show me a programmer as snottily critical of a language as this and I'll show you a programmer who hasn't been one for very long.

        • Give me a PHP programmer and I can tell you he isn't worth anything

          Zuckerberg is worth billions. PHP was mentioned by name several times in the Facebook movie [wikipedia.org].

          When was the last time you heard Python/Perl/Ruby/C++ mentioned in a movie?

          • by lxs ( 131946 )

            Zuck may own billions, but that doesn't really say anything about his worth as a person.

        • by tibman ( 623933 )

          lol, because you can't know more than one language, right?

    • by Anonymous Coward

      The goto seems very arbitrary.
      And since PHP supports exceptions (as far as I understand) what exactly is the point of the goto?
      Literally the only valid use of goto is for error handling, and that is covered by exceptions.
      Every single example they have given could be rewritten using standard control flow.

      • The goto seems very arbitrary. And since PHP supports exceptions (as far as I understand) what exactly is the point of the goto? Literally the only valid use of goto is for error handling, and that is covered by exceptions. Every single example they have given could be rewritten using standard control flow.

        It used to be worse. Much worse. Cobol used to have this notion of "ALTER X TO PROCEED TO Y" whereby X was a paragraph containing a GOTO statement. After the ALTER statement is executed, the paragraph X code was modified to now transfer control to paragraph Y. So you had no idea where the logic flow was going because it depended upon whether or not the ALTER was executed.

        Life was hell.

        • So what you're saying is that PHP is better than COBOL -- hmmm. PHP reminds me of those spider webs made by spiders on different drugs. PHP is like COBOL reimplemented under the influence of which drug, I wonder?

    • by Anonymous Coward

      GOTOs can be a useful language feature, improving program speed, size and code clearness, but only when used in a sensible way by a comparably sensible programmer.

      Linus Torvalds: http://kerneltrap.org/node/553 [kerneltrap.org] (mirror at the Wayback Machine [archive.org])
      Steve McConnell: http://www.stevemcconnell.com/ccgoto.htm [stevemcconnell.com]

  • Honestly. If you can't offer a better solution, stop bitching about it. I and others have asked for something other than PHP for website programming over the past few articles and all I hear is bitching about how bad PHP is.

    I use perl for sysadmin scripting stuff. I like perl. For sysadmin scripting stuff. It's a fricking pain in the ass to set up and maintain for the creation of web pages though.

    [John]

    • by Xest ( 935314 )

      Erm, people have offered better solutions, that's kind of why they bitch.

      I'm very much a best tool for the job type of person but the inherent problem with PHP is that it's really not the best tool for any job any more.

      If you want high quality secure scalable web development then you need something like Java, .NET, or C++ if you actually know what you're doing with it because catching errors at compile time is always better than (possibly not) catching them at runtime. Most issues with type conversion must

  • by Anonymous Coward

    If a job advertises they want PHP in pretty short order you are digging around their Perl code. If a job advertises they want .NET pretty soon you are trying to fix MFC code. I've seen this all throughout my career in programming most times these languages that seem easy or are popular...well usually its just a trap. This separates the men from the boys pretty quickly IMO. Cherry-picking is not for professionals and never has been. In the real world you learn this rather quickly if you intend to survive as

    • i was hired primarily as a php/backend dev. what am i doing? a lot of devops, javascript, and mobile app programming. ah well, at least it makes my resume look fatter (and in turn my paycheck).
    • by Xest ( 935314 )

      I don't think that's a bad thing though. Personally I feel a job where I work with multiple languages (and technology stacks) is far more interesting than just working with the same language and framework day in day out for all eternity.

Things are not as simple as they seems at first. - Edward Thorp

Working...