Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
PHP Books Media Programming Book Reviews

Core PHP Programming 223

honestpuck writes "One of my key concerns when reviewing a good book is the pull between information density and a light, easily read style. I believe that as we get further along the learning curve we can sacrifice some readability for density -- we want more facts and less explanation." Read on for honestpuck's take on the third edition of Core PHP Programming to see how well it achieves that balance.
Core PHP Programming (3rd Edition)
author Leon Atkinson with Zeev Juraski
pages 1041
publisher Prentice Hall PTR
rating 9
reviewer Tony Williams
ISBN 0130463469
summary Good comprehensive guide for beginner to expert

The authors of Core PHP Programming have found a marvelous middle ground. Toward the beginning of the book they have a great deal of light, explanatory material as they cover the basics of PHP. As they move towards more advanced topics there is less explanation and a tighter packing of information. At the same time the book has a large number of small code examples throughout, making sure that you know how to use the functions under discussion.

This is the third edition and I must admit that I had not come across it in either the first or second editions, so I have no great way of comparing them in this review. It has certainly been revised to take into account the changes for PHP 5 and examining the table of contents for the second edition on Safari I can see the that the basic structure has remained the same while the book has grown about 300 pages. The addition of Zeev Suraski as co-author can only be to the benefit of the quality of the information, particularly regarding PHP 5.

The book starts with the absolute rock bottom of PHP, the basic data types and operators through to efficiency, debugging and design patterns. Along the way it covers almost all aspects of PHP 5 with a readable reference style. The 'Core' in the title of this book is a key to understanding it. If you're looking for a book with all the code required to handle session management, or user logins and security (to mention two possibilities) then this isn't the book for you. If, however, you are after a book that more than adequately explains the power and nuances of PHP and programming in the language then this is a marvelous volume.

It's broken up into 5 sections: "Programming PHP," which covers the basics of data, control flow and I/O; "Functional Reference," which is 600 odd pages broken up into 12 chapters that seems to cover every PHP function (a check of three sub chapters showed every function mentioned on the topic at PHP.net was also in the book) and does it well with good explanation and code examples; "Algorithms," which details a number of methods of performing routine tasks such as sorting, parsing and generating graphics; and "Software Engineering," devoted to design, efficiency and design patterns; and finally, there are a seven excellent appendices.

Taken as a whole it does a good job of covering the whole language and the ways of using it.

I can imagine it would make a good companion volume to my other favourite PHP volume, PHP and MySQL Web Development, which tends more towards recipes and leaves out the encyclopedic coverage of this book.

Leon Atkinson has a good page for the book that includes a link to download all the code and examples, a link to the Prentice Hall page for those wanting an example chapter or a look at the Table of Contents and some other reviews. His site also has a page for the inevitable errata, currently blank. While I did find only one typo (not in example code) I can't claim to have read every page or run all the code examples.

I'd recommend this volume to anyone who wanted a comprehensive guide to PHP 5. It is probably useful at almost all levels.

You can purchase Core PHP Programming, 3rd Ed. from bn.com. Slashdot welcomes readers' book reviews -- 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.

Core PHP Programming

Comments Filter:
  • Needed? (Score:2, Insightful)

    by Tyler Eaves ( 344284 ) on Monday January 12, 2004 @01:31PM (#7953717)
    Does one really need a 1000 page reference on PHP? The online documentation is free, downloadable, and quite complete.
  • Re:Needed? (Score:1, Insightful)

    by Anonymous Coward on Monday January 12, 2004 @01:35PM (#7953755)
    Then don't buy the book. Many of us like dead trees we can flip through.
  • by October_30th ( 531777 ) on Monday January 12, 2004 @01:35PM (#7953761) Homepage Journal
    Online documentation is also ugly and hard to read.

    I always print out the manuals, faqs and howtos I read frequently. I also print out important e-mails.

  • Incomplete PHP5 (Score:4, Insightful)

    by TekZen ( 611640 ) on Monday January 12, 2004 @01:40PM (#7953820) Homepage Journal
    I was very excited to get a book that covers PHP5. However, since PHP5 is still changing the book leaves a lot to be desired. There is no information at all on SimpleXML, which will probably be the prefered XML handler once PHP5 is released. When I bought the book I was expecting it to be one of those books that gets worn out from use. However, I haven't touched it in over a month (and I probably bought it 6 weeks ago). I would wait to buy books on PHP5 until PHP5 is out. -Jackson [jaxn.org]
  • by mgkimsal2 ( 200677 ) on Monday January 12, 2004 @01:41PM (#7953827) Homepage
    There's a lot of people who say 'you don't need a book, the online docs are great!'. I disagree.

    *Some* books are good (although I think there are too many which repeat the same information, not enough focus on particular topics in the PHP world) and necessary because they can go into greater detail than you get from the online docs.

    "What about online tutorials?" Some are good, but having it all in one book, written by only one or two authors (as opposed to wrox-style 15 authors) can help keep a consistent presentation of concepts from beginning to end.

    I'm not saying online sucks and all books are great - many PHP books aren't all much more useful than the online docs really. But for those that try to actually teach, rather than reprocess, I think they can be more valuable over time than *just* the online docs.

    Personally, I think this 3rd edition is good, although there is, imo, too much reprocessing of the manual. You could cut 200-300 pages out of this book and not miss much of anything. What would be left is worthwhile, though. What's missing in all the reference material is details on what, if any, differences there are between PHP4 and PHP5. If it's there it's in text form, not a standard icon set to alert you of potential differences.

    BTW, I have roughly the same arguments for PHP training courses, which we teach (subtle plug). "It's all online!" isn't the best answer for everyone. Many people struggle for hours or days with some concepts with only tutorials and reference pages. Put them in a classroom where they can get immediate feedback on new concepts, and they get it much quicker. Each person learns and adapts to new information in different ways, and classroom training is appropriate for some people, whether it's "only" PHP or something else.
  • Re:Needed? (Score:5, Insightful)

    by RetroGeek ( 206522 ) on Monday January 12, 2004 @01:42PM (#7953845) Homepage
    Does one really need a 1000 page reference on PHP? The online documentation is free, downloadable, and quite complete.

    The online docs do not say HOW to program in PHP.

    Yes, they are a great reference, and actually are the best online docs I have seen (mostly due to the comments), but you still need to know how to program to use them.

    OTOH, a good programming book will step you through on HOW to use the various functions, not just what the functions do. Things like layering, magic number constants, security etc.
  • by D-Cypell ( 446534 ) on Monday January 12, 2004 @01:44PM (#7953862)
    Although ive not done too much with it, PHP seems to be fast becomming the de-facto standard for young programmers getting into true dynamic web development on the server.

    Personally I feel that J2EE and JSP is a more 'enterprise' technology for this kind of development with large transactional systems but the nature of PHP tends to lend itself more to the lightweight, free web development and is supported by a growing number of hosting companies (even free hosting companies).

    I do question the need for yet another book on the subject, but i prefer to see up to date copies of books such as this hitting the shelves than "1001 ways to do everything you need with .net".

    Kudos to the PHP team.

  • by Frymaster ( 171343 ) on Monday January 12, 2004 @01:44PM (#7953863) Homepage Journal
    Online documentation is also ugly and hard to read.

    yes, but....

    1. it is always up-to-date
    2. it is complete, ie it archives older versions and deprecated calls
    3. it has user comments usually (php.net's user comments have saved my ass at least twice)
    4. it is free
    5. it weighs nothing. when you walk to work, this counts.
  • Re:Needed? (Score:3, Insightful)

    by Anonymous Coward on Monday January 12, 2004 @01:48PM (#7953907)
    Maybe because PHP5 isnt finalized yet? Kinda stupid to update comprehensive docs for a changing beta...this book would've done better for wait for 5's final release.

    Your comment is rather disjointed, were you trying to link between online docs being unreadable and php5 docs not being online, while claiming the book is exactly opposite, with easy to read PHP5 documentation? Or do you just suck at typing?
  • by Anonymous Coward on Monday January 12, 2004 @01:52PM (#7953946)
    That's not part of the "standard" documentation distribution (check the tarball). I like to have a local copy of the docs so I'm not hitting php.net constantly (and I program PHP for living).
  • by Saeed al-Sahaf ( 665390 ) on Monday January 12, 2004 @02:13PM (#7954138) Homepage
    "Real programmers only write in..."

    ...the language most appropriate for the particular project?

  • Technical Writing (Score:5, Insightful)

    by JediDan ( 214076 ) on Monday January 12, 2004 @02:16PM (#7954168)
    "One of my key concerns when reviewing a good book is the pull between information density and a light, easily read style. I believe that as we get further along the learning curve we can sacrifice some readability for density -- we want more facts and less explanation."

    You've just described some of the basics of good technical writing. The basic theory of writing good technical documentation is identifying your audience and writing so not only does the document answer the audience's questions and provide usefully comprehensible information, but also refers the more literate and technical readers to more detailed sources.

    Anyone aspiring to be a writer - either professional or just notating code - should take a few technical writing classes. There's an industry that's refined the process of technical writing and there's no sense to reinvent the printing press - so to speak.
  • by hyperstation ( 185147 ) on Monday January 12, 2004 @02:46PM (#7954503)
    bs. a new programmer should have to worry about everything that is going to affect the readability of his code in the future when he's an advanced programmer.

    it's hard, very hard to break the bad habits instilled in "new" programmers. get em while they're young. that's why i like the fact that python *forces* good form and whitespace. just the notion that it won't work if it's not properly formatted will carry over to other languages when someone moves on to another language, and good style will as well.

    understanding the difference between tabs and spaces isn't something too hard for anyone attempting to learn a programming language to tackle.

    the parent is gonna get un-modded for this, but i just had to say something...
  • by SmallFurryCreature ( 593017 ) on Monday January 12, 2004 @03:00PM (#7954651) Journal

    Perl is a great tool. But it is more of tool to use on files then a tool to create webpages. Using perl to generate html or rather bits of html is like using a fully loaded factory workshop to hammer in a nail. Overkill.

    Python. No idea.

    C? You gotta be kidding. Compiling each time you make a change to page? C would be like using nanotech to create a new material from wich you can cast a hammer to insert a thumbtack. Overkill doesn't even begin to describe it.

    PHP may have gotten big but at its heart it still does the same what it did originally. Make dynamic websites. Sure you can mess with OO a bit and a lot more in 5 but if you don't want you never need to touch it. You don't need to access any database. You don't need to use shared memory to store variables. But you can if you want to.

    Perl is often used but approaches it from the other side. Great toolset with web added on. PHP is web with a great toolset added on.

    Of course real web developers know both.

  • by Christianfreak ( 100697 ) on Monday January 12, 2004 @03:05PM (#7954686) Homepage Journal
    The problem is number 3. If the documentation is so complete why are the user comments needed? There have been plenty of times I've seen things in user comments that should have been in the actual documentation. That doesn't seem very complete to me.
  • by monique ( 10006 ) on Monday January 12, 2004 @03:16PM (#7954810) Homepage Journal
    I disagree. Coldfusion is the kind of thing a non-programmer can learn quickly.

    PHP has always looked too much like shell scripting or C to be friendly to non-programmers. I love PHP precisely because it is extremely easy for a *programmer* to pick up, but has a lot of functionality with which you can improve your naive first implementation.

    My first PHP programs involved lots of calls to external apps, particularly grep and find. That ability allowed me, as a unix-tool-using programmer, to quickly hack together PHP that I could later improve. But I can't imagine picking up PHP as a non-programmer and having the first clue how to use it.
  • by Christianfreak ( 100697 ) on Monday January 12, 2004 @03:36PM (#7955002) Homepage Journal
    Perl is a great tool. But it is more of tool to use on files then a tool to create webpages. Using perl to generate html or rather bits of html is like using a fully loaded factory workshop to hammer in a nail. Overkill.

    Eh? With Perl you use what you need. Nothing beats CPAN. PEAR? not even close. And when you need something non-standard in PHP (graphics libraries?) You have to compile the whole thing again.

    Then there's all kinds of other things that you just can't do in PHP without rolling your own or trusting the latest snippet from php1337haX0rs.com. What do you do if you need to actually parse html? Use templating that a designer can understand? Even easily manipulate text data?

    PHP embeds scripting in webpages. Its rarely reusable and it often leads to a mess. Its also the kind of thing we used to flame Microsoft for (scriptable email?). Most other solutions sit outside your webpage (and can often even manipulate your webserver) to generate a page for you.
  • Online REFERENCE (Score:3, Insightful)

    by MrChuck ( 14227 ) on Monday January 12, 2004 @06:20PM (#7956664)
    The online stuff is fine REFERENCE material. It answers questions from the "what are the arguments that THIS FUNCTION takes?"

    There are also, like any real world programming language, many ways to approach the same problem.
    Sometimes there are BAD ways (a function might exist to do something simple and quickly and shouldn't be used as part of a more complex solution)

    The online docs don't answer the questions like:
    What's the best way to read in an apps config file and perhaps even write it back out?
    How can I write a random cookie to someone and use that value as a lookup into a database of current state and other information (and expire said info for out-of-date sessions)?
    Can I easily use XML for configs rather than .ini files?

    Books can show best practices, hazards in using certain functions, how some suites of functions best interact with other uses, etc. A book may also elide certain functions that are older and perhaps better replicated in newer functions - code waiting to die (once that PHP2 stuff gets redone).

    This sort of thing has no place in documentation for a list of functions.

    We could call is "user manual" vs. "reference manual". Online docs for PHP are a great reference manual.

  • by moof1138 ( 215921 ) on Monday January 12, 2004 @07:10PM (#7957199)
    I am not a big fan of PHP, but there are good reasons why it has been successful where it is.

    1) A lot of people like to have code tags embedded in their HTML. You can do this in Perl with Mason, or EmbedPerl, or what have you, but good luck getting cheap hosting where you have that set up.

    2) Perl running through CGI has a lot of limitations, it is somewhat slow, you are limited in where you put scripts, etc. These are overcome by moving to mod_perl, but if you have a big server that is serving up a lot of domains as vhosts, which is what a lot of cheap hosting is about, they are not going to want to enable mod_perl, since every script will be sharing the same interpreter and this is not at all secure. I think I read that mod_perl 2 would help with the latter, but even if this is the case, since nobody runs Apache 2 it doesn't really matter.

    So PHP makes it easy to inline code which a lot of people like, especially beginners, and fits well for current hosting limitations.

    There also is the bad reason that there are a lot of crappy free CGIs out there, like the dreck on Matt's Scripts that are security nightmares so some admins have stomped on CGI access because of this. PHP has no advantage here, since there are plenty of PHP security nightmares out there, but the Perl ones have been around longer and been exploited longer, especially the evil 'formmail.pl'. Another PHP plus is that it is easier to sandbox off PHP for admins who have unknown users posting code on their servers.

    Personally I feel sorry for people stuck using PHP. I use mod_perl, DBI, and HTML::Template, and a few other really great CPAN modules, and when I get stuck going back to PHP to do work I find the tools very inconsistent and limited compared to Perl, especially in database programming. But if I were to set up a 'cheap webspace' server I would not trust users with Perl unless I worked hard to cripple it, while I could adequately cripple PHP fairly quickly.
  • Re:Needed? (Score:3, Insightful)

    by Trejkaz ( 615352 ) on Monday January 12, 2004 @07:22PM (#7957327) Homepage

    So basically you fill the first half of the book with a bloated version of the instructions that are already on the web site. Then you fill the second half with a printout of the function library off the web site. Then you just need to put a bit of padding around it all describing a language which isn't even complete yet.

    This sounds worse than the typical Java book scenario, where they fill half the book with dry and obvious instruction, and the second half of the book with the Javadoc printouts. In defense of the Java book authors, the actual web documentation for some of those technologies is very scarce, but this is certainly not the case for PHP!

  • by onomatomania ( 598947 ) on Monday January 12, 2004 @07:29PM (#7957388)
    Yes, and PHP has had to pay a price for that simplicity that appeals to beginners. For example, take the whole "register globals" thing. Well, it sure sounds appealing to a beginner that every field in a form is automatically a variable with the same name in the global namespace. I mean, it's so easy to just say "print $name" or whatever, right? Oh, but wait: you have to meticuously scrub all user-supplied data, otherwise you leave yourself open to cross-site-scripting or SQL injection attacks. And if the user on the other end adds a field to the URL that you didn't think about beforehand, then you now have a new variable in your global namespace that you *may* not have been aware of. Is it really a good idea to expose the entire global namespace of your language to the end user? And yes, they changed the default for this a while ago, somewhere around 4.1 or so. But there are still some bad scripts out there that require it turned on. And there are still dozens and dozens (if not hundreds) of exploits that are still being discovered or are as-yet unpatched because of the lazyness introduced by the mantra of "Don't worry, I'll fill in all the variables for you. You just worry about sticking them in a SQL statement."

    And, until recently the entire language had a flat namespace. If you wanted to create a module to do something you just sort of picked a starting prefix for all your function names and hope that they don't collide with anything. This is surely fine when the language is young, and it must look rather appealing to the beginner -- as in, "Hey, neat, no worrying about all those complicated classes or scoping or namespaces or anything, I just have this extremely long list of functions that I can call." And that sort of organization really doesn't scale. It would not be able to support the 10,000 (or whatever) modules that CPAN offers for Perl. And as the number of PHP modules balloons they realized in 5.x that they needed much stronger class-like typing and organzation, instead of just having a long list of a bunch of functions.

    So, yes, PHP is terribly easy to learn... but that isn't necessarily good from the standpoint of security or long-term language health.

Always leave room to add an explanation if it doesn't work out.