Slashdot Mirror
PHP In Action: Objects, Design, Agility
Michael J. Ross writes "Despite being perhaps the most popular Web language in use, PHP has for much of its history been criticized for not offering the full capabilities of object-oriented programming (OOP). But with the release of version 5, PHP introduced a robust object model, and made it easier for its proponents to create well-architected Web sites and applications. In turn, the new OOP capabilities have facilitated additional best practices, such as design patterns, test-driven development, continual refactoring, and HTML templates. These topics and more are explored in the book PHP in Action: Objects, Design, Agility."
PHP in Action: Objects, Design, Agility
author
Dagfinn Reiersol, Marcus Baker, Chris Shiflett
pages
552
publisher
Manning Publications
rating
8/10
reviewer
Michael J. Ross
ISBN
1932394753
summary
A pragmatic guide to object-oriented PHP development.
Authored by Dagfinn Reiersøl, with Marcus Baker and Chris Shiflett, the book was published on 3 July 2007 by Manning Publications, under the ISBNs 1932394753 and 978-1932394757. Its subtitle accurately reflects the major themes of the work: creating PHP applications built upon objects, utilizing Web-oriented design patterns, and incorporating agile programming techniques such as refactoring and test-driven development. Also covered are methods for effective form handling, database extraction, date and time representation, and more.
As a result of trying to adequately cover such a large number of major topics in a single book, the amount of material is considerable, and the book is certainly longer than the typical Web programming book in general, and PHP book in particular. Spanning 552 pages, the material is organized into 21 chapters, grouped into four parts: In Part 1 ("Tools and concepts"), the authors discuss PHP 5, its strengths and weaknesses, and how well it can be used with advanced programming principles; an overview of objects, exception handling, and references; visibility, abstract classes, and interfaces; effective use of classes and object-oriented design; inheritance, composition, and more on interfaces; advanced object-oriented principles; six design patterns that are especially appropriate for Web-based systems (Strategy, Adapter, Decorator, Null Object, Iterator, and Composite); and lastly, date and time handling using objects.
For developers well-versed in OOP, Part 1 may be more of a review, while Part 2 ("Testing and refactoring") could be the most valuable portion of the book. In the four chapters, the authors dig into the details of test-driven programming, refactoring, and Web testing. These chapters and all that follow take a very pragmatic approach to conveying ideas, which is consistent with the theme of Manning's "In Action" series, based upon the idea that programmers tend to learn best by reading sample code instead of generic discussion. For instance, test-driven development (TDD) is demonstrated by showing how to implement database transactions, a contact manager, and e-mail functionality. Mock objects and top-down testing are illustrated through the creation of an e-mail class, and further extended with a discussion of faking the mail server. Given that testing is the primary theme of the entire part, one might expect a more lengthy discussion of TDD, but Reiersøl correctly notes that this particular book is not trying to replace the many manuscripts and articles already published on agile development; also, the database examples adequately demonstrate the general principles discussed prior. The chapter on refactoring is well worth reading, and touches upon the controversial topic of how much one's PHP code should be separated from the HTML code — a topic later revisited in the chapter on templates. Also explored is a topic critical to maintenance programmers — refactoring versus rewriting. Two different testing frameworks are discussed, PHPUnit and SimpleTest; the latter is used throughout the book. The final chapter in this part explains how to test Web pages programmatically, by faking interaction, and other techniques. The chapter ends with a section providing steps on how to deal with "the horror of legacy code," when the unfortunate programmer has inherited a nightmare of a live Web site.
The third part of the book, "Building the web interface," begins with an examination of templates, the arguments for and against them, and three of the most commonly used template engines: Smarty, PHPTAL, and XSLT. One of the previously discussed design patterns, Composite, is utilized for combining templates to create complex Web pages. The chapter on user interaction makes use of the Model-View-Controller architecture, with the subsequent chapter delving deeper into the topic of controllers for Web pages. The next two chapters cover an area of site development that is a frequent cause of uncertainty, "bandage coding," and security risks: user forms and input validation. The book's coverage of the PEAR package HTML_QuickForm, alone makes it worth reading. Part 3 concludes with a chapter on abstracting database resources through objects and the Singleton pattern.
The fourth and last part of the book ("Databases and infrastructure") is relatively brief, comprising two chapters on marrying SQL with object orientation. The authors present a number of techniques for shoehorning SQL transactions into object-based code, including encapsulating queries inside of methods, building SQL statements dynamically, substituting SQL elements such as column and table names, using SQL aliases, and using SqlGenerator.
It is clear that the lead author, Dagfinn Reiersøl, has put a tremendous amount of time (three years, as noted in the preface) and effort into creating this work. The discussions are wide-ranging and in-depth, and there is just enough sample code to illustrate the ideas being discussed and also break up the visual monotony. The illustrations are limited in number, and consist mostly of class diagrams and UML sequence diagrams. Overall, the treatment of each topic clearly reveals that he has considerable experience with them, and has given thought to the pros and cons of some possible approaches, though not all of them.
However, there are still some weaknesses in the book. For example, in all of the material discussing how to separate the SQL code from the PHP code, I found no mention of stored procedures, such as those made possible in MySQL. All of the sample code appeared to be solid, though there was no clear reason for the inconsistent use of print() versus echo() is different code samples. All of the chapter summaries could be excised without any loss of value, and many of the chapter introductions could be eliminated as well or condensed.
On a more mechanical level, the book had many minor weaknesses: It was not encouraging to see the first erratum even before reaching page 1: "raising own level" on page xix, in the second paragraph. Readers may initially be confused by such attributions as "Uncle Bob [Uncle Bob]" (on page 77). In a future edition, it should be explained that names in square brackets are biographical references listed in the Resources section, which follows Appendix B. In the first sentence in Chapter 12, the reference to "Jackass" will probably be confusing to many readers — particularly non-Americans — and is not in the best of taste. In the text and the table of contents, the chapter and part titles are written in sentence case, instead of title case, for no obvious reason. It is not clear whether this is meant as an unsuccessful attempt at literary hipness, or just an unfortunate reflection of the current text messaging generation, which is eschewing rules of grammar that for centuries have made text easier to read. Finally, there was one problem in the production of the book, and not its writing: Several of the pages had light brown spots on them that were apparently part of the paper, and not a result of post-production staining. But these may be limited to my particular (brand-new) copy of the book.
Readers interested in learning more about the book could start at the publisher's Web page, which features an online table of contents and index, all of the book's source code, two sample chapters (7 and 21) in PDF format, and a link for purchasing the electronic version of the book, also as a PDF file. Any road/code warriors who do development on their laptops, on the go, will appreciate having this book readily available.
Yet most of these objections are minor and easily fixable, and do not detract from the value of this book. I especially liked the depth of experience brought to each topic, and the authors' consideration of differing viewpoints. PHP in Action is a competent, engaging, and detailed discussion of object-oriented and agile programming principles that can help PHP developers boost their effectiveness and the quality of their code.
Michael J. Ross is a Web developer, writer, and freelance editor.
You can purchase PHP in Action: Objects, Design, Agility from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
As a result of trying to adequately cover such a large number of major topics in a single book, the amount of material is considerable, and the book is certainly longer than the typical Web programming book in general, and PHP book in particular. Spanning 552 pages, the material is organized into 21 chapters, grouped into four parts: In Part 1 ("Tools and concepts"), the authors discuss PHP 5, its strengths and weaknesses, and how well it can be used with advanced programming principles; an overview of objects, exception handling, and references; visibility, abstract classes, and interfaces; effective use of classes and object-oriented design; inheritance, composition, and more on interfaces; advanced object-oriented principles; six design patterns that are especially appropriate for Web-based systems (Strategy, Adapter, Decorator, Null Object, Iterator, and Composite); and lastly, date and time handling using objects.
For developers well-versed in OOP, Part 1 may be more of a review, while Part 2 ("Testing and refactoring") could be the most valuable portion of the book. In the four chapters, the authors dig into the details of test-driven programming, refactoring, and Web testing. These chapters and all that follow take a very pragmatic approach to conveying ideas, which is consistent with the theme of Manning's "In Action" series, based upon the idea that programmers tend to learn best by reading sample code instead of generic discussion. For instance, test-driven development (TDD) is demonstrated by showing how to implement database transactions, a contact manager, and e-mail functionality. Mock objects and top-down testing are illustrated through the creation of an e-mail class, and further extended with a discussion of faking the mail server. Given that testing is the primary theme of the entire part, one might expect a more lengthy discussion of TDD, but Reiersøl correctly notes that this particular book is not trying to replace the many manuscripts and articles already published on agile development; also, the database examples adequately demonstrate the general principles discussed prior. The chapter on refactoring is well worth reading, and touches upon the controversial topic of how much one's PHP code should be separated from the HTML code — a topic later revisited in the chapter on templates. Also explored is a topic critical to maintenance programmers — refactoring versus rewriting. Two different testing frameworks are discussed, PHPUnit and SimpleTest; the latter is used throughout the book. The final chapter in this part explains how to test Web pages programmatically, by faking interaction, and other techniques. The chapter ends with a section providing steps on how to deal with "the horror of legacy code," when the unfortunate programmer has inherited a nightmare of a live Web site.
The third part of the book, "Building the web interface," begins with an examination of templates, the arguments for and against them, and three of the most commonly used template engines: Smarty, PHPTAL, and XSLT. One of the previously discussed design patterns, Composite, is utilized for combining templates to create complex Web pages. The chapter on user interaction makes use of the Model-View-Controller architecture, with the subsequent chapter delving deeper into the topic of controllers for Web pages. The next two chapters cover an area of site development that is a frequent cause of uncertainty, "bandage coding," and security risks: user forms and input validation. The book's coverage of the PEAR package HTML_QuickForm, alone makes it worth reading. Part 3 concludes with a chapter on abstracting database resources through objects and the Singleton pattern.
The fourth and last part of the book ("Databases and infrastructure") is relatively brief, comprising two chapters on marrying SQL with object orientation. The authors present a number of techniques for shoehorning SQL transactions into object-based code, including encapsulating queries inside of methods, building SQL statements dynamically, substituting SQL elements such as column and table names, using SQL aliases, and using SqlGenerator.
It is clear that the lead author, Dagfinn Reiersøl, has put a tremendous amount of time (three years, as noted in the preface) and effort into creating this work. The discussions are wide-ranging and in-depth, and there is just enough sample code to illustrate the ideas being discussed and also break up the visual monotony. The illustrations are limited in number, and consist mostly of class diagrams and UML sequence diagrams. Overall, the treatment of each topic clearly reveals that he has considerable experience with them, and has given thought to the pros and cons of some possible approaches, though not all of them.
However, there are still some weaknesses in the book. For example, in all of the material discussing how to separate the SQL code from the PHP code, I found no mention of stored procedures, such as those made possible in MySQL. All of the sample code appeared to be solid, though there was no clear reason for the inconsistent use of print() versus echo() is different code samples. All of the chapter summaries could be excised without any loss of value, and many of the chapter introductions could be eliminated as well or condensed.
On a more mechanical level, the book had many minor weaknesses: It was not encouraging to see the first erratum even before reaching page 1: "raising own level" on page xix, in the second paragraph. Readers may initially be confused by such attributions as "Uncle Bob [Uncle Bob]" (on page 77). In a future edition, it should be explained that names in square brackets are biographical references listed in the Resources section, which follows Appendix B. In the first sentence in Chapter 12, the reference to "Jackass" will probably be confusing to many readers — particularly non-Americans — and is not in the best of taste. In the text and the table of contents, the chapter and part titles are written in sentence case, instead of title case, for no obvious reason. It is not clear whether this is meant as an unsuccessful attempt at literary hipness, or just an unfortunate reflection of the current text messaging generation, which is eschewing rules of grammar that for centuries have made text easier to read. Finally, there was one problem in the production of the book, and not its writing: Several of the pages had light brown spots on them that were apparently part of the paper, and not a result of post-production staining. But these may be limited to my particular (brand-new) copy of the book.
Readers interested in learning more about the book could start at the publisher's Web page, which features an online table of contents and index, all of the book's source code, two sample chapters (7 and 21) in PDF format, and a link for purchasing the electronic version of the book, also as a PDF file. Any road/code warriors who do development on their laptops, on the go, will appreciate having this book readily available.
Yet most of these objections are minor and easily fixable, and do not detract from the value of this book. I especially liked the depth of experience brought to each topic, and the authors' consideration of differing viewpoints. PHP in Action is a competent, engaging, and detailed discussion of object-oriented and agile programming principles that can help PHP developers boost their effectiveness and the quality of their code.
Michael J. Ross is a Web developer, writer, and freelance editor.
You can purchase PHP in Action: Objects, Design, Agility from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Cue the PHP vs Every Other Language debate..
404 when loading the publisher's website... I wonder if it's written in PHP?
J/K. Programming bigots are all wankers in my book.
In another 5 years we'll be able to run neural nets on PHP!
What a nice ad for a book. How'd this get past the firehose spam filtereing mods?
This looks like a great book for those of us already stuck with PHP. For the rest, I'd suggest avoiding it entirely. PHP 5's OOP is still pretty awful and still has many caveats which have simply never existed in other languages. For example, the exception handling is pretty useless as it generates "Fatal error: Exception thrown without a stack frame in Unknown on line 0" when used in a number of contexts.
I do web development & design for a living. I use PHP because it is what I got into and I have not yet had the time and/or drive to really try anything else. PHP is so available and that is its real strength. It's biggest problem is those lazy folks who are still running 4.2.x or some branch that is or is to be discontinued very soon here. As well there are some known exploits and issues in the older branches.
I love the rapid-ness of PHP though. At present I even use PHP-GTK2 to prototype all of my idea's while I learn new languages. That is, I'll make a rough draft in PHP-GTK and then try to do the same in C/C++... which is much more painstaking for someone who has used web development for so long. But I am slowly un-learning my habits to depend on magic to handle memory for me, etc.
Yup. Just my random bablings.. I am sure there was a reason I started writing this comment.
Bingo, sir.
"under the ISBNs 1932394753 and 978-1932394757"
The former is a traditional ISBN. The latter is what was (or is) called a Bookland EAN (978 is like a country code you'd find in any EAN, specifying that the rest of the numbers make up an ISBN.) They're both ISBNs now, as ISBN space expansion necessitated reformatting, but I guess my point is that, while they're different formats, they represent the same ISBN. The review makes it sound like they're different printings.
Get over it. PHP is not perfect, but it does a damn good job. If it didn't, it wouldn't be so widely used. You can respectfully disagree, but try to maintain some civility here instead of suggesting we all just avoid PHP as if it's some kind of curse. There isn't a tool in the world that doesn't have it's flaws.
I've been using PHP for eight years and there hasn't been a day where I wished I had chosen another language. Sure, I wish the PHP of today was available eight years ago, but I can't complain with what is available now.
For he today that sheds his blood with me shall be my brother.
Seriously, it has nothing to do with the fact we're sick and tired of cleaning scripts written by people who don't know what they're doing, and we like blocking access to your site for major vulnerabilities. We actually love it how when your script gets owned, you don't notice for months because you do the development on the server, all the while jerkoffs are udp-flooding from your site. Because you'll never pay for this usage, and you'll expect us to fix your script, it doesn't matter because we're just really upset that it isn't "offerring the full capibilities of object-oriented programming".
That and we sometimes wonder what it would be like to fling poo...
As a complete programming noob looking to get into web-related design and things of that nature, what languages are good to start with and to branch to other languages? Would that be like C-> PHP -> SQL? What other languages apply and/or in what order are languages needed to learn to start to bring things together for well designed websites?
PHP: Because 10 million newbies can't be wrong.
While I agree with the latter overall, I dispute "robust object model." What's missing? Polymorphism is sketchy, and static initializers are missing, for two. In PHP5, you can only initialize static properties with literals or constants - no function or method calls.
Also, calling up the inheritance chain, to a grandparent class's implementation of a method, is difficult to say the least.
While PHP5 is a *lot* better than PHP4 (and probably Perl if one took the time to compare) - it's not really comparable to truly robust OOP languages such as Java, Smalltalk and C++.
Mind you, I code in PHP5 for a living. It gets the job done, but it has to be called on its limitations, and you gotta be honest and tell programmers who want OOP from PHP5 that it has limits, and how to work around them. None of this "robust object model" stuff.
O lord, bless this thy holy hand grenade, that with it thou mayest blow thine enemies to tiny bits, in thy mercy.
Nope. PHP has been criticized for:
I could go on. Not all of these are really legitimate complaints, or a reason not to use the language; indeed, it has evolved. Due to the amount of code that exists in PHP, and the amount of cheap hosting which runs some form of PHP, I can no longer accuse people of being stupid for choosing PHP, although I might call them insane for liking it if they've given anything else half a chance.
But I wouldn't put a lack of basic OOP particularly high on the list, especially with how dysfunctional the OOP was when it was finally added.
Disclaimer: As much as I enjoy flamewars, and although I realize this will feed one, that's not why I'm posting. I'm just posting to clarify -- if you thought all PHP needed was OOP, you're dead wrong. If you're trying to improve PHP, look beyond OOP. (Look especially to the mysql_add_slashes_no_really_i_mean_it_this_time() functions, and compare them to Perl's support for prepared queries.)
Don't thank God, thank a doctor!
I've used Smalltalk, C++, Java, Python etc. 1st time experience using PHP in real OO dev with phpUnit. I have enough pain with PHP language defects that remind me with the pain with C++. This is my wisdom, use PHP carefully like C++ as there are a lot of language traps behind the close door. The biggest defects is the array comparison. I think PHP is doing copy-on-write behind the scene; but the lacking of way to compare the object identity is a real pain. Both '==' & '===' are fooling. There are still a lot defects I've discovered. I think I have enough content to write an anit-pattern for PHP.
Maybe a ./ editor can fix the link in the article for the rest of us ;-)
The publisher link in the article should have been: http://www.manning.com/reiersol/
Thanks in advance
For something that doesn't require the complexity of OOP, I think PHP does a decent job of getting what u need done quickly...assuming you're not a tard of a programmer. I like it's syntax (I come from a C background), as compared to Perl (which resembes the illegitimate child of C and LISP with down syndrome). Not to mention the documentation via www.php.net is nice.
But that very nature lends itself to a paradigm that makes it far too easy to eschew software engineering principals. So you reap what you sow.
Yes, you can do OOP in PHP. But on large projects - and especially multi-programmer projects - you or somebody on your team is probably gonna wind up succumbing to doing things the way the language makes easy.
Now excuse me while I go write some sparkly, gorgeous Python code.
Dan.
How can I consider a language that was created by an irrational person?
"But with the released of version 5, PHP introduced..."
Any reasonable 10 year old word processor grammar check would catch this. Or Slashdot can just hire a 10 year old.
a robust object model, and made it easier for its proponents to create well-architected Web sites and applications.
I've never seen good examples of OOP making websites or typical business clearly better. Any bad non-OO coding presented was merely poor knowledge of procedural, bad specific languages, or lack of knowledge about good relational techniques. I challenge anybody to clearly demonstrate OOP being better for the mentioned domains.
I've found flaws with the OO books out there. For one, they assume unrealistic change patterns to artificially boost OO. And please no anecdotes; for those are not dissectable. If OO fits your own personal psychology better, that's fine, but I don't wear your head.
Table-ized A.I.
That error is a result of throwing an exception where it can't ever be caught. This is YOUR FAULT entirely and not PHP's fault, but nice try shifting blame and all that.
Just because you can't build a tree house doesn't mean it's the fault of the hammer. Nice try shifting blame though, you really sound far more intelligent than me and my crass reply to your idiocy.
I'm god, but it's a bit of a drag really...
PHP, or "Personal Home Page" to us old time users (Not PHP Hypertext Processor, as some revisionists would have to believe.) is a simple web scripting language first envisioned in the 90s for making simple web pages.
.NET environments, and things like JSF or Swing are HUGELY complex and difficult to manage. With a continuum between simple HTML docs to HUGE applications, PHP sits in a very wide middle ground that it easy to manage and deploy.
For what it is, PHP is pretty good, a quick and dirty scripting language that, if used right, can make some pretty impressive applications.
The real problem with PHP is the bickering and infighting little boys club that is the PHP development community. Over time they've learned a lot, but for the most part they believe they know everything and everyone else is wrong. Even though there are public forums, decisions are made on IRC chats. It is not as transparent or well functioning as groups like Apache, PostgreSQL, and others. A lot of petty crap goes on behind the scenes and a lot of people who would have been active contributors get pissed off and leave.
I could go on with first hand and second hand stories and it is my opinion that it is this lack of professionalism that hinders PHP quality and adoption on an enterprise level.
All that being said, PHP has a solid purpose in the web world. Java and
As someone who's been using PHP for about 7 years (and someone who's gotten quite wealthy because of it), I have to say, among its many inadequacies, the insane inconsistencies PHP has with naming conventions makes me want to eat glass. I say with PHP 6.0 they should deliberately break backwards compatibility and go with one solid naming convention for methods and functions. I don't care if they go with functions_with_underscores or functionsInCamelCase, just as long as it's consistent.
I chose to work with PHP due to its flexibility. Writing software by creating types is useful in certain places, but I have found that it tends to require more code to be written than is needed for most web applications. Many of the applications which I currently maintain have been written elegantly using basic GET and POST checking and a series simple of functions.
My problem had nothing to do with destructors. There are other contexts where they can't be used. But of course you knew that, even though they're not really documented.
function a() { new DateTime('2007-02-32'); }
function b() { a(); }
register_shutdown_function('b');
And even then my complaint isn't that you can't do that, but that there is absolutely no way to track down the source of that error because unlike most other PHP errors, you're told it's on line 0 of Unknown.
Maybe this isn't the spot to post this, but I will anyway:). I've been looking into learning a good web developing program, I am wondering what most people prefer. I have been toying with PHP a little, but recently have been pointed in the direction of Python. After reading some of the comments in here I'm curious what are your thoughts?
You could spend all day listing the problems with PHP, but one that doesn't get mentioned nearly enough is:
.htaccess and apache configs too, so don't just test from the command line), but I long for the day when PHP is just the same for everybody when it starts up, and settings must be changed *at run time* or in some automateable way.
PHP.INI means there are thousands of variations of the language.
See, I'm one of those crazy people who values predictability and precision in my software. For instance if my software assumes that a number is always less than 100, the database better fucking enforce that constraint, otherwise I consider it a bug in either the software or the database. Likewise, if my development machine has safe mode off, I want to ENFORCE that the deployment machine also has safe mode off, and so on.
And having to make sure all the settings in PHP.ini are right when deploying software is simply ridiculous. Does it allow short tags? Is safe mode on? File uploads allowed? AUTO QUOTING BULLSHIT \' \' (what were they thinking)??? Session handling? Session timeouts?
I have deployment scripts now that automatically verify all this BS (don't forget, you can change some settings in
It amazes how little PHP programmers complain about this and other limitations of PHP. Either they are incompetent, or they have accepted a level of unpredictability in their software even higher than the programming community at large.
Good grief, not another pointless language A is better than language B discussion. Fact of the matter is, is that not one language exists that will work perfectly in all situations. Pick the right tool for you and for the job at hand. For dynamic web pages, PHP does a pretty damn good job (think about how many Java web apps could have easily have been done more efficiently in PHP??..don't lie), but you certainly wouldn't be building any desktop applications with PHP.
And for the love of God, quit comparing interpreted scripting languages to languages like Java/C++...that doesn't work.
"Several of the pages had light brown spots on them that were apparently part of the paper, and not a result of post-production staining."
Good lord! Are you sure? Were the pages a bit wrinkled too?
Taken from http://www.bitstorm.org/edwin/en/php/
1. Bad recursion
Recursion is the mechanism in which a function calls itself. This is a powerful feature which can make something complex something simple. An example of a function using recursion is quicksort. Unfortunately, PHP is not good at recursion. Zeev, one or the developers of PHP, says this: "PHP 4.0 (Zend) uses the stack for intensive data, rather than using the heap. That means that its tolerance recursive functions is significantly lower than that of other languages." See bug 1901. This is a poor excuse. Every programming language should provide good recursion support.
2. Many PHP-modules are not thread safe
A couple of years ago, Apache released version 2.0 of its web server. This version supports multithreaded mode, in which one piece of software can run multiple times simultaneously. The makers of PHP say that the core of PHP is thread safe, only the non-core modules often aren't. But nine out of ten times, you do want to use such a module in your PHP-script, making your script unsuitable for Apache's multithreaded mode. That's why The PHP Group doesn't recommend running PHP on Apache 2 in multithreaded mode. The bad multithreaded mode support of PHP is often seen as the reason Apache 2 still didn't catch on.
3. PHP is crippled for commercial reasons
The performance of PHP can be increased to 500% by using caching [benchmarks]. So why is caching not build into PHP? Because Zend, the maker of PHP is selling its own Zend Accelerator and of course, they don't want to cannibalize on there own commercial products.
4. No namespaces
Suppose someone creates a PHP-module that can read files. One of the functions in this module is called read. And someone else's module can read web pages and also contains a function read. Then it is impossible to use these modules together because PHP will not know which read function you want.
An easy solution to this is namespaces. It was a suggested feature for PHP 5, but unfortunately it didn't make it. Now, without namespaces, every function has to be prefixed with the module name, to prevent name collisions. This leads to terrible long function names like xsl_xsltprocessor_transform_to_xml which makes code harder to write and read.
5. Non-standard date format characters
Many programmers are familiar with the date format characters known from UNIX and the C programming language. Other programming languages adopted this standard, but strangely enough, PHP has its own, completely incompatible date format characters. While in C, "%j" stands for the day of the year, in PHP this stands for the day of the month. To make things even more confusing: the function strftime and the date_format of Smarty, a PHP templating engine, do use the C/UNIX format characters.
6. Confusing licenses
You might think PHP is free and all PHP-modules in the manual are free too. Wrong. For example, if you want to generate a PDF-file from PHP you will find two modules in the manual: PDF or ClibPDF. But both come with commercial licenses. So for every module you use, you have to make sure you agree with its license.
7. Inconsequent function naming convention
Some function names consist of more than one word. There are three conventions for combining these words:
1. Glued together: getnumberoffiles
2. Separated with underscores: get_number_of_files
3. Camel case: getNumberOfFiles
Most Languages choose one of these variants. PHP uses all of them.
For example, it you want to convert special characters to HTML entities, you use the function htmlentities (Words glued together). If you want to do the opposite, you use its little brother function html_entity_decode. For some reason the words are now separated by underscores. Why is this bad? You know there is a function named strpad. Or was it str_pad? Every time you hav
The reason why people use php is because of the huge list of built-in functions. I would prefer to use ruby (I love the way it handles), but I can't be bothered to spend 3 months hunting down and/or coding every string and numeric function that ruby doesn't have built-in. I've seen other people's ruby's projects, and they're not pretty to look at -- thousands upon thousands of lines of code extending String and Fixnum just to provide basic functionality that is provided for you with no hassle in php.
I refuse to touch other people's php code unless my job depends on dealing with it. Most people who code php don't even realize that $var = $_GET['foo']; can return an array. Let alone the fact that people still write code for fucking 4.x, which just pisses me right off. Yes, everyone programs differently, and every programmer thinks their code is written better/cleaner/more secure than everyone else's. But seriously, there are far too many php coders who learn only as much as they have to in order to "get the job done".
I think my biggest peeve with php is the fact that var_dump("1e1" == "10"); evaluates as true (for some truly fucked up reason, comparing 2 "numerical" strings converts both operands to integers).
echo foo(1);
:-O
Which, in reality will work better in the second place.
For the love of god, please don't learn "a language". There are a million dorks out there who know a language or two, but can't program worth shit. Don't get hung up on "the web", either.
First, learn to program.
"Despite being perhaps the most popular Web language in use, PHP has for much of its history been criticized for not offering the full restrictions of object-oriented programming"
There, fixed that for you.
kthxbye!
need a free COBOL editor for Windows?
This, along with the generic O'Reilly PHP reference book, is the only useful PHP book I've ever read. I would recommend it.
Maybe I'm just lazy,
I'll accept that. I grew up programming in Pascal and BASIC, turned to C/C++ and loved it through college and my first 8 years of my software development career, dabbled in Java for a year - and then found PHP. For the last 5 years I have been programming in the language of my choice - PHP - and loving it. It's quick, it's easy, it's powerful. I find it just as easy to write a web server (Yes you can write a web server in PHP - the networking and forking functions are great - I've even successfully written apps that use COM to manipulate Excel) as it is to write a web app.
Maybe my past experience allows me to write structured code without having the language force me to write structured code. Maybe my ideas of OO is backwards - I look at data as "black data" and functions "just handle it" rather than forcing the programmer to know what the data is in a strictly typed language (C++/Java).
If you *want* to handle memory allocation - yeah - C/C++ is for you. But when you do that you're solving programming problems. You're not solving the customers problems. When you're a software developer you should be developing solutions for your customers - not solutions for the language you're developing in.
Are there issues with PHP? Of course. Is it THE language to use? Only if you know it and it fits the problem you're trying to solve.
-CF
PHP in action, moar like PHP inaction, amirite?
Remember folks, the acronym for PHP Object Oriented Programming is POOP.