Forgot your password?
typodupeerror

PHP Hacks 165

Posted by samzenpus
from the tricks-of-the-trade dept.
Michael J. Ross writes "Given the current popularity of the Web development language PHP, it makes sense that newcomers to the language have a large number of introductory and reference volumes from which to choose. But for the more advanced PHP programmer, there are far fewer titles that explain how to make the most of the language, by applying it to solve relatively substantial problems. One such book is PHP Hacks: Tips & Tools for Creating Dynamic Websites, by Jack D. Herrington. Read the rest of Michael's review.
PHP Hacks
author Jack D. Herrington
pages 468
publisher O'Reilly Media
rating 8
reviewer Michael J. Ross
ISBN 0596101392
summary Practical techniques and source code for improving PHP-based Web sites and applications.


The book was published by O'Reilly Media in December of 2005. Despite its title, PHP Hacks: Tips & Tools for Creating Dynamic Websites is clearly intended to show how PHP's capabilities can be extended beyond its most common usage for creating dynamic and database-driven Web pages, and can be employed in such areas as graphics, reporting, Web site testing, code generation, and even fun purposes (for those few programmers who find the former topics less than entertaining). The author, assisted by six contributors listed in the Credits section, manages to pack an impressive number of general programming ideas and PHP-specific topics within this title's 468 pages. The material is grouped into 10 chapters, each of which contains a generous number of "hacks," each in its own section.

As with most if not all of the other titles published by O'Reilly, this book has a Web page that offers an overview of the book, its table of contents, all of the book's code (in both Zip and tar file format), and a list of confirmed and unconfirmed errata. In addition, the site hosts five sample hacks (in PDF format): accessing iPhoto pictures, generating Excel spreadsheets, avoiding the "double submit" problem, reading RSS feeds on your PSP, and creating custom Google Maps. Perusing these hacks would give the prospective buyer a clear sense as to the style of the book's other 95 hacks, as well as the (low) level of PHP expertise needed to understand them.

The book begins with a preface that describes the organization, conventions, and icons chosen for the book. Also, it covers the legality of the code samples, lists contact information, and mentions O'Reilly's Safari online book service, which contains this title among many other PHP resources. What is perhaps most unique about this book's preface is that the author identifies over half a dozen weaknesses commonly seen in PHP applications, and explains how his book addresses those problems. In addition, he makes explicit how some of the hacks can be used for jazzing up one's Web site or Web-based application.

The first chapter discusses how to install PHP on Windows, Mac OS X, and Linux, and then verify that the installation was done properly. Herrington then briefly explains how to install MySQL and perform some basic database management. The chapter concludes with coverage of installing the PEAR library on your local machine and on your Web host's server (which is incorrectly identified as your "ISP machine," apparently assuming that most developers choose their Internet service providers for hosting their sites, when in fact the opposite is true). Since the typical reader of a non-beginning book such as this no doubt has one or more introductory and/or reference PHP books at hand, it would seem superfluous to waste time and space explaining how to install these components. But few pages are taken up by the material.

The next chapter is devoted to hacks that help to jazz up the design of one's Web sites, including how to create a skinnable interface, build a breadcrumb trail, create HTML boxes, add tabs to your interface, and other valuable techniques. Subsequent chapters offer hacks in the areas of dynamic HTML (DHTML), graphics and digital pictures, databases and XML, application and e-commerce design, patterns and PHP object orientation, testing and documentation generation, and building alternative user interfaces. The 10th and final chapter covers some "fun stuff," such as creating dynamic playlists, developing a media upload/download center, and even putting Wikipedia on a Sony PlayStation Portable.

Rather than try to explain in detail all of the many topics covered in the book, I instead encourage the interested reader to visit the publisher's Web page, and scan through the table of contents provided, to get a better idea as to how much of the book would be of interest to the individual. Also, the five sample hacks listed on the site, would be well worth examining and trying out. Overall, the topics chosen reflect favorably upon the judgment of the lead author and the other contributors to the book. The typical PHP veteran would likely be interested in most of the applications covered, and would probably learn some new tricks, especially in the areas of patterns and code testing, regardless of their level of experience.

Like all books, this one is not perfect. As with the first printing of most technical books; particularly those chock-full of source code; the book contains a fair number of errata, likely even greater in number than those reported and listed on the publisher's Web site, as mentioned earlier. Consequently, any reader who chooses to test the sample code and he or she would be encouraged to do so; should keep one browser window or editor buffer open and devoted to those errata, so as to minimize the time spent trying to figure out why some sample code is not working as advertised.

Some readers posting in forums have complained that the sample code has evidently not been fully tested on all platforms, nor in all Web browsers. Since few if any reviewers would have the time, resources, or inclination to verify these claims, it should suffice to simply bear in mind that the script output and other behavior detailed in the book might not exactly match those experienced during one's own usage of the code.

The fact that there were several cooks in the kitchen brewing up this particular book, is obvious from the way that the code formatting is not consistent throughout the book, as well as the variety of problem-solving styles. Fortunately, neither weakness is of much consequence, and the latter might even be considered a "feature," as it allows the reader to see how a number of veteran PHP developers approach solving a problem.

Most technical works written by a team of authors, end up as excessive "doorstops" that are often frustrating to read as a result of the wildly inconsistent writing and coding styles, to say nothing of the material often being out of date as a result of the long production time needed by the publisher. The opposite case can be even worse, when a publisher releases a book that was clearly thrown together as quickly as possible to capitalize upon a hot new trend in technology. Thankfully, PHP Hacks keeps the style differences to a minimum, and benefits from having a lead author responsible for the book as a whole.

Some programming purists may take issue with the use of the term "hack" used as a synonym for a small PHP application or the use of such for solving a problem, since the majority of the PHP scripts in the book do not involve any programming or problem-solving that would be considered notably clever or elegant. Yet the misuse of the term seems to be spreading, and is not limited to this particular book ; another example of marketing overpowering stability of language. In the preface of PHP Hacks, the author explains that he uses the term in the positive sense of creative participation, to help reclaim it from its popular usage in place of the more traditional term "cracking," i.e., breaking into systems.

Yet aside from these complaints, PHP Hacks is a worthy title that offers explanations and source code for many valuable site-enhancing applications, testing and code generation techniques, and critical e-commerce safeguards. I recommend this book to any PHP developer who would like to add to their Web sites' capabilities, as well as their knowledge of what PHP can do.

Michael J. Ross is a freelance writer, computer consultant, and the editor of the free newsletter of PristinePlanet.com."


You can purchase PHP Hacks: Tips & Tools for Creating Dynamic Websites 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.

PHP Hacks

Comments Filter:
  • Hacks? (Score:3, Insightful)

    by mikeal (968191) on Wednesday July 05, 2006 @05:24PM (#15663070)
    What defines a "hack" these days.

    Maybe I'm a bit bitter, and even at the risk of sounding like a troll I'm just gonna say it, isn't writing ANY decent amount of php kind of a hack.

    Personally I'm a django fan, I really respect the rails kids for what they are doing too. Once you start doing web development in a real dynamic language you realize that web development in php in most cases IS a hack.

    I've written lots of php over the years, and I'm so glad to know that I NEVER HAVE TO DO IT AGAIN. Unlike in other languages the "hacks" in php tend to be a necessity for doing development in the language. I've really tried to write "clean" code in php and it's just not possible for any project of a decent size.

    Any disagreements?
  • You do (Score:5, Insightful)

    by Unski (821437) on Wednesday July 05, 2006 @05:31PM (#15663112) Journal
    it's just the fashion at the moment. Bashing Java is a classic, but PHP, like 80's ra-ra skirts and lip gloss, goes in and out of fashion constantly. Just stick to praising R-o-R, that'll keep the karma nice n' safe.
  • Re:Hacks? (Score:1, Insightful)

    by Anonymous Coward on Wednesday July 05, 2006 @05:41PM (#15663194)
    I disagree, you probably just couldn't figure out "how to" hack it to make it work for big projects.
  • by Nos. (179609) <andrew@th[ ]rrs.ca ['eke' in gap]> on Wednesday July 05, 2006 @05:42PM (#15663204) Homepage

    Yup, but this comes down to what all dicussions do when a PHP topic is posted to slashdot. Is it the fault of the language when a lot of open source applications are written poorly? There have been very few vulnerabilites in PHP, but lots in apps like Mambo, *Nuke, phpBB, etc.

    I like PHP, I can develop stuff very quickly in it, and I know how to secure code against CSS, SQL-Injection, etc. There are shortcomings with it, like basically every other language, but I don't think the fact that all these application with vulnerabilities should be a direct reflection on the language itself.

  • by dedazo (737510) on Wednesday July 05, 2006 @06:19PM (#15663393) Journal
    Is it the fault of the language when a lot of open source applications are written poorly?
    Why not? That's the reason why Visual Basic was considered "worthless", as if it were inherently impossible to create something useful (well documented, maintainable, stable, etc) with it.

    Not that I agree with either view, but it seems to me PHP is no better than Visual Basic in this regard.

  • by Anonymous Coward on Wednesday July 05, 2006 @06:37PM (#15663484)
    I don't see why everyone is so critical of PHP. PHP does have its downfalls like any other programming language but there are a lot of things that make it so much easier. PHP has a lot of functions and although some people critisize this, it makes it much easier to accomplish many different tasks. I am a person who programs in PHP almost everyday and have been doing so very a few years now and I will admit that things such as magic quotes (though easily fixed) are a pain for beginners and worries such as SQL Injection and careful use of session variables do make development time longer. However there are also a lot of different frameworks out there. Infact, I am writing my own for a client right now which I will later use as part of my portfolio to join a future project. Search Google or Sourceforge and you will find hundreds of these frameworks and APIs which solve many of these problems so that you don't even have to think of them. When I am done with my current project, I can't wait to take a look at some of these frameworks myself. I've been programming in raw PHP for a long time and would love to see what they have to offer. The only reason I haven't is because I am required to know and teach raw PHP to students for my high school's website class and because my recent client requested a custom framework and CMS. However for every day developers and hobbyist, they can make PHP just as versatile as Ruby on Rails.
  • by FooAtWFU (699187) on Wednesday July 05, 2006 @06:39PM (#15663494) Homepage
    Is it the fault of the language when a lot of open source applications are written poorly?

    Yes. The language doesn't actually compel you to write insecure code, but it would be hard to imagine one which came closer. It's practically begging for injection everywhere. You need to manually escape everything. Database work? Sorry, no prepared statements. Going to send mail()? Leave a few newlines in the wrong variable and you can turn your form into a lean, mean spamming machine! Going to try and call system() with any sort of parameters? Quick check: do you want escapeshellcmd, or escapeshellarg? (and of course, you HAVE to use the shell.) There's more, much more, and if that's not enough, two words should make your skin crawl: "register globals".

    use strict; use warnings; taint mode? In your dreams maybe...
    Model-view-controller design? ... I think they used a shotgun on it.

    GAAH.

  • Re:You do (Score:5, Insightful)

    by Fnkmaster (89084) on Wednesday July 05, 2006 @06:43PM (#15663512)
    It sends shivers of disgust down the spine of every serious developer.

    Unlike Perl?!?! Perl is just a foul, disgusting-looking beast. While the PHP libraries may be a touch on the fragile and "arbitrary" side, compared to the libraries in Java, for example, the language itself is like Miss America to Perl's Roseanne Barr.

    The "serious developers" who used to write web apps in Perl and TCL, when those were the two most popular choices for such things back in the day, generally produced write-only web monstrosities that could never be picked up or figured out by anybody else, "serious developer" or not.

    PHP is relatively fast, simple, syntactically straightforward, and easy to work with. This makes it a good choice for a variety of web applications, though obviously not always the best choice. For some of us, getting the job done is more important than feeling like an elite hax0r.
  • Despite what? (Score:2, Insightful)

    by JudgeDredd (561957) on Wednesday July 05, 2006 @06:44PM (#15663518) Journal
    The book was published by O'Reilly Media in December of 2005. Despite its title, PHP Hacks: Tips & Tools for Creating Dynamic Websites

    Umm, despite its title, what?
  • by PCM2 (4486) on Wednesday July 05, 2006 @06:47PM (#15663530) Homepage
    PHP has a lot of functions and although some people critisize this, it makes it much easier to accomplish many different tasks.

    In my experience, it's not so much a case of an embarrassment of riches but more like what the parent said -- it feels like a bunch of hacks. For example, standard library functions that seem similar in almost every respect, save that they work on different data types, take different parameters (or accept them in a different order). This can be very frustrating for experienced programmers who want to get up to speed quickly. Presumably it's less of a worry if you're just learning on PHP.

    I don't hate PHP. I don't really like it, either, though. I'm one of those people who is quick with a snide comment about it whenever it's brought up, just because it has always feels so amateurish, poorly designed, and slapdash to me. That said, you can do some pretty decent stuff given a database abstraction layer and Smarty templates (for example). And the one big advantage it has over Ruby on Rails is that it's available on just about every cheapie $5/month Web host around, whereas RoR is barely supported.

  • by Anonymous Coward on Wednesday July 05, 2006 @07:07PM (#15663615)
    Yes, PHP is relatively easy to begin coding in, what with its fairly forgiving variable typing (or what some would call non-typing) and its babysitting of memory. I would even agree that PHP tends to attract more bozos and wannabes for this very reason. However, PHP is, and continues to be the most widely used non M$ language for open sourced web applications. This is because it works. Sure, PHP allows sloppy coding, but it also allows clean and well written code. PHP is a lightweight, nimble, comprehendable scripting language that is very well suited for its intended environment: the web.

    -Peter
  • by MacFanMR (870166) on Wednesday July 05, 2006 @07:19PM (#15663664)
    All of those observations are true, but that doesn't mean you shouldn't use PHP. As with any tool, you must consider the user, their skill level, and the project requirements when making your decision.

    Many of PHP's inconsistencies stem from the fact that it is an open source language. While it has likely changed now, many functions were accepted into the source without anyone ensuring a consistent naming scheme, parameter order or behavior. To maintain backward compatibility for what is now a very large user base, this cannot be easily changed at this point.

    Several of the examples of redundant functions are not redundant at all. The escaping functions relate to the specific database they are escaping the data for. Oracle requires that things be escaped differently than MySQL, a single function wouldn't work.

    That aside, there are many functions that perform tasks you could accomplish in other ways. For instance, finding if a string contains another string. I might use strpos('mystring', 'my') but there is also a function that is named specifically for the purpose of finding whether a string contains another string. That function would return a simple true/false while my example would actually return the position of the substring or false but I can interpret it to tell me what I need to know. My guess was that the extra functions are an attempt to make the language accessible to less experienced programmers. For me, I would rather write my own functions as needed than muddy the PHP parser with extra functions, but I'm not on the development team so it's not my decision to make.

    PHP has namespaces though they are not formal and therefore not as efficient. For example, all the MySQL functions begin with mysql_ and pSpell functions begin with pspell_. Starting with PHP5 and full OOP support, they now have class based namespaces like SOAPServer::addFunction(). Each namespace regardless of type, represents a package compiled into PHP. Though the default compile comes with many packages installed, you can decrease the number of functions by compiling without support for DBs and other packages you don't need. This would decrease the number of functions PHP is parsing for (correct me if I'm wrong on this.)

    Perl may be compact, but if you notice in the examples, for someone who isn't familiar with Perl, the code provided wouldn't be immediately understandable, and Perl code can be optimized and obfuscated even more than that.

    On the flip side is Java, which at its core is compact, but with the Java standard library of methods, there are nearly unlimited numbers of methods to do just about anything and everything you could ever think of. Add to that the frameworks that exist: struts, beans, servlets, jsp... just to scratch the surface and we find that Java is infinitely flexible and powerful. For those that know it, it is probably the greatest thing ever, but for someone starting out, it is incredibly overwhelming.

    If you use PHP and it fulfills your needs, then keep using it. If you run into a lot of limitations or frustrations because it can't do things you could do in xyz language, or because you are building projects that become difficult to maintain due to their scale, then you might want to explore other options. Ruby/Perl/Java/ASP/Cold Fusion has its pros and cons as much as PHP or anything else. It's up to you as the professional to evaluate your specific needs and options and make the right decision for you.

    Michael
  • Free PHP bashing (Score:4, Insightful)

    by Beuno (740018) <argentina@gma[ ]com ['il.' in gap]> on Wednesday July 05, 2006 @08:29PM (#15663930) Homepage
    I understand that PHP has a very solid newbie user base, but let's not forget monstrous sites like Digg and Wikipedia run on PHP + MySQL
  • by Cl1mh4224rd (265427) on Wednesday July 05, 2006 @09:10PM (#15664115)
    What's also ironic is that Alanis's song doesn't contain a single actual instance of irony.
    That's the irony...
  • Uhhhh (Score:2, Insightful)

    by Anonymous Coward on Wednesday July 05, 2006 @09:17PM (#15664152)
    Did any of you failed PHP programmers ever think maybe its your own ability to write well formed code?

    Since many of the largest and most complicated sites in the world use PHP flawlessly, I think its just your amateurish programming style requiring a compiler to bitch slap you till you do the right thing. That's like blaming the razor blade company when you finally relive us PHP programmers from having to listen to your bitching by committing suicide. Just because you have the freedom, doesnt mean you shouldn't exercise self control.

    Incidentally, if you use PHP for a few months you will find the names to functions coming pretty automatically. You could also grab a copy of an IDE like Zend Studio which shows a list of possible function endings, descriptions and a param summary (even for user defined functions, respecting namespace and supporting classes).
  • by lbft (950835) on Wednesday July 05, 2006 @10:45PM (#15664507) Homepage
    Database work? Sorry, no prepared statements.

    PHP has had prepared statement support for MySQL since 2003, it's been emulated in PEAR for an eternity and the very useful PDO extension provides an abstracted interface supporting prepared statements to SQL Server, Sybase, Firebird, Informix, MySQL, Oracle, PostgreSQL, SQLite, DB2 and ODBC.

    (and of course, you HAVE to use the shell.)

    Forgive me, but you don't know what you're talking about. There is almost never a need to call external apps from a PHP script. The most common needed external app is ImageMagick (because sometimes GD doesn't provide all the functionality you need.) Even then, there are at least two PHP extensions to deal with ImageMagick directly, as well as a PEAR package to abstract away from the image processing library/app.

    Quick check: do you want escapeshellcmd, or escapeshellarg?

    Well, I dunno, do you want to escape an entire command so that multiple commands can't be injected or do you want to escape a single argument so that multiple arguments can't be injected? Heaven forbid that you should have to spend ten seconds checking the manual [php.net] pages [php.net]...

    Going to send mail()?

    So use one of the multitude of classes specifically written to encapsulate mail sending (including, shock horror, one in PEAR.)

    two words should make your skin crawl: "register globals"

    register_globals has been disabled by default for six (6) years.

    It's not the fault of the language that you didn't bother to keep up with how to use it as it evolved.

  • Re:You do (Score:5, Insightful)

    by Tablizer (95088) on Wednesday July 05, 2006 @10:53PM (#15664539) Homepage Journal
    how immature of a language PHP is. PHP is good for simple pages, but other sites should seriously move to something else until the framework matures a lot.

    I would like to see concrete examples of other languages being "better". The skill of the programmer matters far more than the language in my experience, and PHP gives you enough options to make good code *if* you want to.

    The spaghetti code that PHP seems to encourage in a lot of people

    This is because PHP is "approachable". It does not differ enough from C and JavaScript to scare people away, unlike other languages. The "elitist" languages are not necessarily better, they just scare away amatures and newbies so that you don't have as many amatures and newbies writing messy code. Perhaps this is a good thing, perhaps it means that the elitist language is doomed to obscurity. If PHP can make both crowds fairly happy, it will have lasting power. I've never met a language that makes everybody happy, but if diverse sides each give PHP a B-minus, that is doing about as well as you can as far as diversity.
           
  • by mcrbids (148650) on Thursday July 06, 2006 @03:23AM (#15665405) Journal
    So, yeah, there's a reason every is critical of PHP.

    I'm on the other side. What is it about a language that makes it *EASY* to consider the problem at hand, and doesn't make you worry too much about implementation details?

    Using PHP, you don't have to worry about things like memory management and/or memory type translation. A "1" becomes a 2 when you add a 1 to it.

    Arrays and hashes are the same. Any array can be accessed as a hash, any hash is also an array. Makes it easy to define data in memory, then do loops/recursion on it to get whatever result you want.

    Simple!

    Time spent solving customer problems rather than implementation problems is time spent making money instead of wasting it.

    I've written some really big projects with PHP. (EG: over 50,000 lines in 3+ years, with NO HTML CODE) It's done a magnificent job. It scales nicely and easily with it's "share nothing" approach [zefhemel.com], and is highly reliable. In the 6 years that I've been actively developing with PHP, the number of times that there was a bug/problem with the language I could count on one hand, with 4 of the fingers peeled down. It's reliable and scalable enough that Yahoo uses it as their preferred development language. [com.com]

    And, as far as security, the vast majority of issues have been with idiots writing insecure scripting, which can be done in any language. (Yes, I'm thinking of you, SPAW editor!) And, if you're using a decent operating system [centos.org] with an update mechanism (EG: yum) then updates to fix found security issues is a no-brainer.

    With PHP-GTK you can write quick, powerful, cross-platform GUI applications with ease and speed [php.net] - I've done so, managing a distributed database application among some 70 school districts with many hundreds of users - and it works marvelously.

    PHP may have it's warts, but it's a damned fine tool. Don't let anyone convince you otherwise.
  • by Mattintosh (758112) on Thursday July 06, 2006 @06:51AM (#15665883)
    Your entire post is trollish and whiny, but I thought I'd point this out, as it gave me a chuckle:

    But then, Perl never pretends it will keep programmers secure, while PHP tries to and fails.

    followed immediately by:

    Perl also has the immensely important "taint" mode, where unprocessed user input isn't allowed anywhere near important functions, like executing an external program, writing data into the database or selecting a file to open. It's this that forces programmers to think properly, and does a far better job than PHP's attempt to keep you safe without making you think about security. PHP has nothing like taint mode, and it desperately needs it.

    So Perl never pretends to keep programmers secure with some sort of "taint mode" but PHP is retarded because it aims to protect its users by not having such a feature? Huh? You either have it backwards (Perl is actually your overprotective mother while PHP lets you just get things done) or this "taint mode" is a security hole placed there by design (which forces me to call into question the sanity of the Perl guys).

    Just to give you an idea where I'm coming from, I'm a professional PHP developer. I also do C, C++, and Java, and I can pick up just about any other language quickly. Perl is one of only two languages that usually makes my eyes bleed. The other one is Objective-C, and that's mostly because I hear "C" and think it's going to actually be readable. IMNSHO, Perl blows and I wish it would die. Why? Well, for example, the "eq" "operator". Operators are made of non-alphabetic symbols for a reason: so I, the programmer, can pick them out and tell them apart from the non-operators (variables, literals, constants, keywords, and function calls). Now, Java has the stupid String.equals() function. That's bad enough, but at least it's a function. Having alphabetic operators makes unreadable code as bad as any COBOL program ever dared to be (yes, I've endured COBOL). Oh, wait, that's right, this is Perl we're talking about here. Nobody can read that anyway. Poor language design is not soley the domain of PHP.
  • Re:You do (Score:3, Insightful)

    by Senjaz (188917) on Thursday July 06, 2006 @08:11AM (#15666086) Homepage
    Maybe I'm just elitist, but why would you make all of your objects face eastward? Oh, you meant object oriented programming.

    No, I meant orientated, which is totally valid and its use prevailent in England. Which incidentally is where I live.

    The web hasn't changed. It's still a stateless, every-page-for-itself environment. PHP isn't a "page processor", it's a pre-response request processor.

    The web is still stateless but if you don't have to reload your page each time you want to perform an action and redisplay new data then you can develop your entire web app UI in a single page. Then not holding state across page loads doesn't matter any more.

    PHP is known as a page processor, scripts operate on a page by page basis, or as you say a request basis since these things don't have to be pages these days. Just because that's the state of things now, doesn't stop PHP being a page processor. It's only one step up from old style Perl (pre modperl) in that it doesn't need to launch a new process for each request. However PHP is still based around one script being run to handle each resource request. Worse my presentation layer is mingled in with my control and model implementation.

    With Tomcat/Struts I can create an application that is running regardless of whether a request is made or not, it has state. I can build an app separated out in the MVC pattern. I don't care that it's still using the same HTTP transport mechanism, I have an app and it has state.

    You have got to be kidding me. JavaScript is a prototyped language. You don't define objects so much as you lay out a template for one and implement a library that pretends to operate on this so-called "object". It's about as OO as old-school C. In C, you could define a struct and segregate off a header and implementation for it and call it an "object", but there was no enforcement other than internal constraints you imposed upon your own code. JavaScript is just about as strict.

    Javascript is a prototyped language, but just because it doesn't implement OO concepts in the way you expect them doesn't mean it's not OO. Prototyping just means there is no such thing as classes, just other objects which can be used as templates for creating other object instances. It is just as expressive, but different to C++, Java, C#. It's well suited for shallow "class" hierarchies which use other objects rather than deep sub-classing. See Apple's Foundation and AppKit frameworks along with Objective-C as an example of just how powerful this methodology can be.

    In Javascript almost everything is an object, the few native non-object types that are in the language are transformed into objects when you try to use them as such (evaluating: "moo".indexOf("o"); will result in 1).

    One of the benefits of Javascript is that it is not strict. It's incredibly dynamic. It supports inheritance (through prototype chain) and reflection. Looks very object oriented to me.

    Keep using JavaScript and you'll keep moving toward the 1980's. Meanwhile, the rest of the world will continue going forward.

    I guess you think that Google maps and the like are not moving forward then?

    I forgot, this is slashdot. It's got a vocal set of anal retentives/people who don't have a clue which make it difficult to separate signal from noise.
  • What a coincidence (Score:2, Insightful)

    by petroele (81470) on Thursday July 06, 2006 @11:13AM (#15667189) Homepage
    I just bought this book last week. I'm mainly a C++/Java guy but I've been doing lots of PHP over the last year or so. To stay on topic, I was fairly happy with the content of the book. Probably about half of it was stuff I already knew or stuff that was useful but really not PHP specific (DHTML, Javascript, OO design patterns). But there were also quite a few useful hacks that made it worthwhile. Overall, it is good book for thumbing through in your spare time to pick up some new tricks.

How many QA engineers does it take to screw in a lightbulb? 3: 1 to screw it in and 2 to say "I told you so" when it doesn't work.

Working...