Slashdot Mirror
PHP 5 in Practice
Michael J. Ross writes "Computer programming books come in all varieties, but there are at least four general categories: introductory texts, which typically have the lowest content per page; language references, which have become increasingly supplanted by online sources; "advanced" treatments, which are often a mishmash of errata-riddled articles; and "how-to" books, usually at the intermediate level, and sometimes presented as "cookbooks." It is that last category that has been growing in popularity, and for good reason. When an experienced software developer needs assistance, it is rarely for language syntax, but instead a desire to see how someone else solved a specific problem. For solutions using the PHP language, one source of information is PHP 5 in Practice." Read the rest of Michael's review.
PHP 5 in Practice
author
Elliott White III and Jonathan D. Eisenhamer
pages
456
publisher
Sams Publishing
rating
8
reviewer
Michael J. Ross
ISBN
0672328887
summary
One of the most meaty, immediately useful, and fluff-free PHP books available
The book was authored by Elliott White III and Jonathan D. Eisenhamer, and put out in July 2006 by Sams Publishing (an imprint of Pearson Education). Given today's standards of hefty technical books, this particular one is relatively light, weighing in at 456 pages, which are organized into an introduction, numerous chapters, and three appendices.
Its introduction is more interesting than that of most similar books, whose introductions usually consist of formatting conventions and explanations as to why the book was written — all such content providing little to no value to the impatient programmer facing a deadline, and invariably ignored (the content, that is, not the deadline).
White and Eisenhamer took a refreshingly different tack, and chose instead to explain their use of coding standards, comments and whitespace, braces and parentheses, PHP short tags, PHP mode, and other language considerations that are more useful than the typical rundown of somewhat childish icons used in other texts, such as light bulbs and red warning signs.
Switching to the other end of the book, we find three appendices. The first one briefly discusses issues one might face in migrating from PHP version 4 to 5. The second introduces the Standard PHP Library (SPL), and the objects related to its primary design pattern, the Iterator. The third appendix discusses what composes the bulk of output from my PHP programs: error messages. Seriously, this appendix is worth reading, if only for the suggestions as to what to look for when you encounter some of the most common PHP error messages.
The bulk of the book's material is divided into 20 chapters, which are themselves divided into two parts: PHP internals, and applications. The internals are: strings, numbers, time and date, variables, arrays, functions, classes and objects, and files and directories. Starting off with a discussion of strings, might seem odd to the neophyte programmer, but to the veteran who has had to learn several languages during their career, the choice makes a lot of sense. There must be countless developers out there who, being fluent in the C language and object-oriented concepts, jumped into writing their first C++ program, and had to hit the books for the first time when they wanted to do some non-array-based string handling.
The book's second part covers some of the most common applications in PHP programming: Web page creation (using XHTML and CSS), Web form handling, data validation and standardization, sessions and user tracking, Web services and other protocols, relational databases and other data storage methods, e-mail, XML, images, error reporting and debugging, and user authentication and encryption. That last chapter, in the next edition, should be relocated so that it precedes or follows the chapter on sessions and user tracking.
Many of the chapters begin with a "Quick Hits" section, which briefly summarizes how to perform many of the most common and essential tasks related to that chapter's topic. For instance, in the chapter covering the use of variables, this first section explains how to: check if a variable has no value or if it is empty (not synonymous in PHP), undefine a variable, cast it to a certain data type, and do the same thing for a value. There is one minor erratum that should be noted: On page 71, in the first "Quick Hit," it reads "a variable has bee. given a value." ("been"'s "n" ended too soon.)
Each section within the chapter briefly explains the problem domain, and then presents sample code to solve the given problem. The code itself is fairly well commented, and the variable names are adequately descriptive (unlike in some programming books, whose coding standards border on the criminal).
All in all, the book offers a lot of worthwhile solutions to a wide range of problems, and does so in a straightforward manner. It is for this reason that it is not evident as to why this particular PHP title has received so little notice. For instance, on Amazon.com, it has received only one reader review, as of this writing, and does not even make it into the top quarter million books ranked in sales by Amazon.com. It is a pity, because the book deserves much more attention.
Even though this book is to be recommended, and is packed with code and text that are well worth studying, it has one unmistakable weakness for which this writer can think of no adequate justification. The book contains almost no illustrations, even when they are clearly called for — in fact, especially in those cases. For instance, the section that shows how to generate a calendar, does not show a calendar! The code is present, but the sample output — which is what the poor reader would appreciate, to see the results of the code — is missing.
Granted, an absence of figures and screenshots might be understandable for the first part of the book, which covers the PHP language itself. But the second part, covering applications, has far too many unillustrated PHP scripts. These include sections focusing on drop-down menus, progress bars, and graphical charts Web forms. In the last chapter, there is a section with code that generates captchas, but the reader is not shown what they look like. The entire 18th chapter is devoted to images, but contains not a single one! I cannot imagine why the authors and/or publisher chose to leave out these essential graphics. Was it to save money? Whatever the reason, it was a significant mistake, and one that should be corrected in the next edition.
Readers who agree with this assessment, or who have other thoughts concerning this otherwise excellent book, can leave feedback via the book's Web page on the Web site for Sams Publishing. This page offers details on the book, a description and table of contents, links for requesting instructor or review copies, and a tool for searching the book's contents within the Safari online technical library. The book's introduction states that the Web site hosts all of the code listings, as well as a list of errata. Yet, I was unable to find either one. (Sadly, the Pearson Education sites are still some of the least usable in the technical book publishing world.) Much better results were obtained on Eli White's site.
Despite an inexcusable and almost complete lack of needed illustrations, PHP 5 in Practice is possibly one of the most meaty, immediately useful, and fluff-free PHP books available. No serious PHP programmer should be without it.
Michael J. Ross is a Web consultant, freelance writer, and the editor of PristinePlanet.com's free newsletter. He can be reached at www.ross.ws, hosted by SiteGround.
You can purchase PHP 5 in Practice from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The book was authored by Elliott White III and Jonathan D. Eisenhamer, and put out in July 2006 by Sams Publishing (an imprint of Pearson Education). Given today's standards of hefty technical books, this particular one is relatively light, weighing in at 456 pages, which are organized into an introduction, numerous chapters, and three appendices.
Its introduction is more interesting than that of most similar books, whose introductions usually consist of formatting conventions and explanations as to why the book was written — all such content providing little to no value to the impatient programmer facing a deadline, and invariably ignored (the content, that is, not the deadline).
White and Eisenhamer took a refreshingly different tack, and chose instead to explain their use of coding standards, comments and whitespace, braces and parentheses, PHP short tags, PHP mode, and other language considerations that are more useful than the typical rundown of somewhat childish icons used in other texts, such as light bulbs and red warning signs.
Switching to the other end of the book, we find three appendices. The first one briefly discusses issues one might face in migrating from PHP version 4 to 5. The second introduces the Standard PHP Library (SPL), and the objects related to its primary design pattern, the Iterator. The third appendix discusses what composes the bulk of output from my PHP programs: error messages. Seriously, this appendix is worth reading, if only for the suggestions as to what to look for when you encounter some of the most common PHP error messages.
The bulk of the book's material is divided into 20 chapters, which are themselves divided into two parts: PHP internals, and applications. The internals are: strings, numbers, time and date, variables, arrays, functions, classes and objects, and files and directories. Starting off with a discussion of strings, might seem odd to the neophyte programmer, but to the veteran who has had to learn several languages during their career, the choice makes a lot of sense. There must be countless developers out there who, being fluent in the C language and object-oriented concepts, jumped into writing their first C++ program, and had to hit the books for the first time when they wanted to do some non-array-based string handling.
The book's second part covers some of the most common applications in PHP programming: Web page creation (using XHTML and CSS), Web form handling, data validation and standardization, sessions and user tracking, Web services and other protocols, relational databases and other data storage methods, e-mail, XML, images, error reporting and debugging, and user authentication and encryption. That last chapter, in the next edition, should be relocated so that it precedes or follows the chapter on sessions and user tracking.
Many of the chapters begin with a "Quick Hits" section, which briefly summarizes how to perform many of the most common and essential tasks related to that chapter's topic. For instance, in the chapter covering the use of variables, this first section explains how to: check if a variable has no value or if it is empty (not synonymous in PHP), undefine a variable, cast it to a certain data type, and do the same thing for a value. There is one minor erratum that should be noted: On page 71, in the first "Quick Hit," it reads "a variable has bee. given a value." ("been"'s "n" ended too soon.)
Each section within the chapter briefly explains the problem domain, and then presents sample code to solve the given problem. The code itself is fairly well commented, and the variable names are adequately descriptive (unlike in some programming books, whose coding standards border on the criminal).
All in all, the book offers a lot of worthwhile solutions to a wide range of problems, and does so in a straightforward manner. It is for this reason that it is not evident as to why this particular PHP title has received so little notice. For instance, on Amazon.com, it has received only one reader review, as of this writing, and does not even make it into the top quarter million books ranked in sales by Amazon.com. It is a pity, because the book deserves much more attention.
Even though this book is to be recommended, and is packed with code and text that are well worth studying, it has one unmistakable weakness for which this writer can think of no adequate justification. The book contains almost no illustrations, even when they are clearly called for — in fact, especially in those cases. For instance, the section that shows how to generate a calendar, does not show a calendar! The code is present, but the sample output — which is what the poor reader would appreciate, to see the results of the code — is missing.
Granted, an absence of figures and screenshots might be understandable for the first part of the book, which covers the PHP language itself. But the second part, covering applications, has far too many unillustrated PHP scripts. These include sections focusing on drop-down menus, progress bars, and graphical charts Web forms. In the last chapter, there is a section with code that generates captchas, but the reader is not shown what they look like. The entire 18th chapter is devoted to images, but contains not a single one! I cannot imagine why the authors and/or publisher chose to leave out these essential graphics. Was it to save money? Whatever the reason, it was a significant mistake, and one that should be corrected in the next edition.
Readers who agree with this assessment, or who have other thoughts concerning this otherwise excellent book, can leave feedback via the book's Web page on the Web site for Sams Publishing. This page offers details on the book, a description and table of contents, links for requesting instructor or review copies, and a tool for searching the book's contents within the Safari online technical library. The book's introduction states that the Web site hosts all of the code listings, as well as a list of errata. Yet, I was unable to find either one. (Sadly, the Pearson Education sites are still some of the least usable in the technical book publishing world.) Much better results were obtained on Eli White's site.
Despite an inexcusable and almost complete lack of needed illustrations, PHP 5 in Practice is possibly one of the most meaty, immediately useful, and fluff-free PHP books available. No serious PHP programmer should be without it.
Michael J. Ross is a Web consultant, freelance writer, and the editor of PristinePlanet.com's free newsletter. He can be reached at www.ross.ws, hosted by SiteGround.
You can purchase PHP 5 in Practice from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Chapter 1 will discuss building PHP CLI classes that download and install OpenJDK. Chapters 2-22 will teach you Java.
I was right with you there buddy, until you mentioned Ruby/RoR and C#/VB/.NET
I'm a bit disappointed to read in the book review that there wasn't a chapter dedicated to security. Considering that PHP will let you do things like do external includes from other web servers that can modify your PHP environment, etc...
What PHP needs is not more features, but better designed security model.
Yes Francis, the world has gone crazy.
"PHP is not a real language" flame war starts in: 5, 4, 3, 2...
You were one post late... admittedly, he was very polite for a troll.
BlackNova Traders
... I was too till he missed out perl.
Only three things are certain; death, taxes, and apocryphal quotations - Ben Franklin.
Most programmers use only a subset of a given language. That suffices for 99% of what they want to do. When they have a problem, they will indeed appreciate finding someone else's solution. The problem is that whoever coded the solution probably did not use exactly the same subset of the language. That means the programmer will either: a) paste in the solution if it works without modification. or b) hit the books to try and figure out how the solution works. That often means looking up the syntax of something unfamiliar.
...
So; a little from column A and a little from column B
> ... I was too till he missed out perl.
;-)
**shudder**
I've loved PHP for the last few years. If it has taught me anything it's that Snape kills Dumbledor in Harry Potter. Enjoy PHP! I know I do.
VB?
thissounds() like_a_really() interestingBook()
A few years back (circa 2002), I whipped up a rapid application prototype with PHP while working off from some on-line tutorials and using Beginning Php 4 from Wrox. I think the book and the tutorials were good a teaching the basic language features and syntax, but they taught me to use PHP dangerously because they did not teach good practices. My application worked but never got out of the prototype/demo stage back then for business reasons. Recently, I went back to it on my own time to try to clean it up, move it to PHP5, and make it deployable. I now cringe with horror at the extremely bad practices I was using back then. Granted, it was just a prototype, but I thought I was doing it "right" because I was following the examples in the book and the tutorials. I was doing stuff like accepting form data and passing it to the DB with out validation, outputting user submitted variables without checking for XSS, registering globals, etc, etc, etc. I was doing the kind of things that give me nightmares now.
/* trust us on this part for now, we'll show you how this part works latter, just remember you always have to validate the input before you use it */".
So here is my point, all the tutorials, examples, and books that the neophytes are using to learn are _WRONG_. They are teaching _BAD_PRACTICES_. Because PHP is necessarily meant to be in a network environment (excluding the rarely used cli) and it WILL be exposed to potential maliciousness, secure practices should be taught markedly at the beginning, not as an aside. So as part of teaching how to pass form parameters they should include validation code, even if they have to comment that section as "
I think PHP is a great language for its purpose, which is simple web-apps. Lots of the criticism about its brain-dead defaults is correct, but they can be overcome with good practices by the application developer. PHP can be great, but it is typically taught wrong at the beginning and that just snowballs.
The editors and authors all the PHP books and tutorials out there need to make sure the new editions encapsulate good practice at the beginning of the learning process.
first disclaimer- I haven't read this particular book. I hope it is better than the other PHP books to which my comments apply.
Second, disclaimer- this is mostly a repost from my post at this discussion ( PHP Application Insecurity - PHP or Devs Fault?)
What the hell? How can you write about captchas without showing pictures?
How else do you get this point across properly?sucks.
I recently finished up Gone With The Wind. Would you consider this book:
A. Funnier than GWTW
B. Just as funny as GWTW
C. Not as funnier as GWTW
Your valued insight into this fine work would be greatly appreciated and it would help me make my next book purchase easier.
Thanks in advance.
Another one of those huge low-density books of examples. Do we really need another one.
What's really hard today is finding a good reference manual. The original manual for Algol was 17 pages. The original manual for Scheme was 21 pages. 456 pages for PHP is a bit much. A big plastic card that boiled the language down to two pages - now that would be useful.
Barnes and Noble is selling this book for $39.99, but Amazon.com is only selling it for $28.39!
Save yourself $11.60 by buying the book here: PHP 5 in Practice. That's a total savings of 29.01%!
Non affiliate link
With languages like Ruby, Python, Perl, etc. around, why bother with PHP?
PHP has:
It does however have a good documentation. Without it though, programming PHP would be impossible. Try coding PHP without the documentation at hand.
"Was it function_name($foo, $bar) or functionname($bar, $foo)? Or rather prefix_function_name($foo,$bar,$baz) where $baz is always empty?"
I could go on and on. These are just the facts. What I ignored are the countless hours I wasted trying to debug some perfectly good looking piece of code only to find out in the end that PHP is the problem. On that occasions PHP ate away a part of my soul. (pretty poignant, eh?)
And yes, in case you wonder, I did very large PHP stuff. Megabytes of code in CVS. Luckily no more. (Could be written in kilobytes of Ruby anyway.)
Meme of the day: I browse "Disable Sigs: Checked". So should you.
> PHP 5 In Practice
Way shorter book summary:
Don't.
Are you SURE it was PHP? I wonder how you could spend "countless hours" debugging PHP code? I've been at the PHP language for years and the one thing you CAN say about PHP vs other languages is that it shouldn't take "countless hours" to debug. I mean...countless hours? Ate your soul? Perhaps programming isn't really for you. Maybe sales? or marketing?
You'll have that sometimes...
I needs to look into this Ruby thing. Can you recommend any good Ruby books? I know there's plenty of stuff online, but I'd much rather read through a book for stuff like this.
I'd go on and say that IMO (which genuinely is humble, as I'm a sysadmin who's prepared to look at and tweak code if necessary, rather than a fulltime dev), PHP has promulgated an entire mass of badly written, badly commented, ill conceived code.
Sure, it's possible to write bad code in any language. But PHP is like the BASIC of the web. Popular, (yes, there was a time BASIC was popular) yet treated with contempt because it's just so easy to shoot yourself hard in the foot. At least with C, you usually know pretty early on if your code is really badly thought up. With PHP, however, it seems that nobody quite realises what a festering mess they've produced until someone else points it out, by which time it's taken as a personal attack.
With languages like Ruby, Python, Perl, etc. around, why bother with PHP?
Hide the kids; here comes another language/paradigm holy war....
Table-ized A.I.
I've gotta agree with some of the presuppositions and points in this review. PHP - in the right hands - is a powerful language. It's great that you can whip things up quickly. But too many of the books go through the fairly simple bits in mind-numbing detail (like, I know what an array is). Thanks to Eclipse and oXygen, most of the time that I'm at a screen, my editor can load the documentation in to a panel while I'm typing it (along with remembering class names, variable names and so on). If I'm coding PHP (or a lot of other languages, for that matter), Eclipse has the language reference. And oXygen gives me the documentation from XSD/RNG/DTD schemas for XML/XHTML etc. Language references aren't useful in dead tree format.
But something that dead tree can be useful for is conveying development experience. Of course, this can be transmitted in other means. Books that give me best practice guidelines are often far more useful than language guides. For instance, in PHP, there is a function called file_get_contents(). It does what it says. You give it a URL or file and it reads it in to a string. But what the language reference *doesn't* tell you is that for getting things off the 'net libcurl is a better way of doing it - it's quicker, more powerful and has a lot of extremely useful options - in short, something which, if one is intent on building a serious web application in PHP, one should probably use. This is one of the reasons why I think language references would be better if managed on a wiki - or, as PHP does it, with comments attached. That way, people can post code samples, bug reports, workarounds, common errors and so on. This is useful.
A measure of a successful technology book these days has to be "does this make me a better developer?". The fact that we have books which deal with best practice means that online documentation has gotten better and better and publishers are responding to that. Most of the languages and frameworks I use I carry the specifications for on my Palm Pilot in Plucker format. Reference books can't compete with that. A few publishers I've seen are shifting towards a tutorial style (in the web design sphere, Friends of Ed is a good example of this).
catch (HumourFailureException e) { e.user.send("You, sir, are a humourless idiot."); }
With regard to the link you provided under "no usable object-model" - I would have to agree with the PHP developers on that one. self::$var or self::CONSTANT is supposed to bind statically. That is how self is supposed to work and actually what the bug reporter was trying to achieve is impossible in C# too AFAIK.
Namespaces are upcoming in PHP6 (again, AFAIK).
The rest of the observations are correct to the best of my knowledge and make PHP quite a horrible choice for all projects beyond a certain complexity threshold. Personally I wouldn't think of Perl as a substitute, even though I understand in many respects Perl is superior to PHP, I just find it difficult to make the right choices when it comes to picking a module for a given job. I think Perl suffers from a lot of duplicated effort, there is no concerted effort to establish a de facto framework of modules.
PHP is dying a slow death in my eyes because of all the inconsistencies. The object orientation feels more like a patch or a workaround rather than a core architectural choice. The total mess created by the ton of functions in the core is not going to go anywhere with the devs maintaining backwards compatibility indefinitely.
I think that decoding captchas using PHP would have been a more interesting chapter.
And in the rare case when you actually find that bug, it turns out you can't fix it because the whole card-house would crumble into oblivion if you did. So you build workarounds (which accumulate) that are the heralds of death of the system.
I should have said that I did not in fact write the whole 30ish MB code base myself. I inherited it and got to live with it or do something else. It wasn't planned, it wasn't built using development methodologies (think XP, Scrum, etc.) but rather using a whip. The explanation for the system then is something along the lines of "It has grown organically.".
And although I see myself primarily as a programmer, I am in fact working on extending my abilities to encompass marketing. So your evaluation flatters me.
Meme of the day: I browse "Disable Sigs: Checked". So should you.
How do I know?
(Could be written in kilobytes of Ruby anyway.)
bullshit
This person has probably never coded PHP, but has programmed in other languages much, and jumped ship to ruby.. He is a Ruby fanboy, He has the sense to search bugs that point out some flaws in PHP, but I can easily paste links to a bunch of ruby bugs. Yet the mods are so fucking blind they don't see this.
Furthermore, Ruby compared to PHP is an even lazier language. You probably dont have to understand many programming concepts if you can cut countless hours into minutes with Ruby. The language does not encourage strong security, good coding practices, and last time I checked the development of the project is only a few years old. I remember PHP's functions just fine, and are you going to make fun of c++ or java for their wierd naming of functions and classes? And don't get me started on the original Ruby "how to code ruby in 10 minutes" video, where the guy is having to change the config files over and over just to get the thing to work.. Mod parent flaimbate..
Amusingly enough I have encountered the same sort of frustration that the grandparent post author has. Just never ever try to write a SOAP server using the core SOAP module :D I mean it, you will go insane in a matter of days.
Even for day-to-day tasks, because PHP makes simplicity it's creed you will run into all sorts of problems the minute you grow your project into something bigger. Most of the problems I have run into were undocumented or poorly documented "features", I'll admit, but on occasion the dent my head left in the wall was caused by pure and simple brain damage on the part of the PHP developers. The SOAP core module is a good example. PDO is another. I was once considering switching from the PEAR DB layer to PDO, given that it was advertised as a superior solution and given that PEAR in particular is a very bad piece of programming one should avoid at all costs. On paper PDO looks great. The implementation sucks. Half the time the database was returning an error the PHP process would segfault.
Consider this, many a year has passed since Apache mpm-worker has been around as a stable and reliable solution. Even to this day I am forced to rely on mpm-prefork. PHP would randomly segfault otherwise, because some of the core modules are not yet multithreading aware.
I have a hard time believing you really worked with PHP for any length of time. While some of your points are in the ballpark of valid, for the most part you're just repeating the PHP slander I hear all over the internet. The fact is you can shoot yourself in the foot in any language. The reason PHP takes so much heat is because it's free,it's popular and it's extremely easy to learn and so it's easy for beginners to make mistakes like not filtering/validating user input and not escaping output, but any experienced developer should know to do this. I'd like to hear you point out an example of a bug that took you HOURS to debug. I really would.
Well, theres why's (poignant) guide to ruby which is licensed under creative commons. So it could be that somebody made a book on demand out of it. Personally I used "Programming Ruby" of which the first edition is also available online. "Rails Recipes" is a very good reference book for repeating patterns using Ruby on Rails. Rails though also has it's annoyances so I am trying to find an excuse to build something with Django and Python.
Meme of the day: I browse "Disable Sigs: Checked". So should you.
As someone who's spent more than 4 years with PHP, I couldn't agree with you more. The only thing PHP has going for it is that it is widely supported among web hosts. I also think that Ruby and Python syntax may scare off a lot of people, whereas PHP is pretty much C syntax.
Similes are like metaphors
> Namespaces are upcoming in PHP6 (again, AFAIK).
That's nice. Is not segfaulting when the stack depth is exceeded also a planned "feature"? Because every report on the problem is still WONTFIX.
Picking on PHP just isn't worth the effort anymore. Nor is waiting for it to be fixed.
Done with slashdot, done with nerds, getting a life.
Let me tell you something about the slander you hear all over the internet: It's all true.
Meme of the day: I browse "Disable Sigs: Checked". So should you.
Now that's useful.
Today I could use ones for Perl and Python; I'm converting someone else's regular expressions from Perl to Python. Both have almost the same syntax.
In perl's defense, I think that's sometimes the biggest reason I choose perl over the others. The good thing about duplicating or reinventing the wheel is sometimes you need different wheels for different tasks. It also facilitates evolution and a plethora of ideas that you would otherwise miss if you had put everyone together and told them to make THE ONE best module because there will always be drawbacks to even particularly good implementations. The result is perl's library (cpan.org) is massive. When I look at other things like Ruby, though I like the language features, the library work simply isn't there yet.
As a side note, there's some really cool libraries out for perl. Check out moose or catalyst for example.
Here is a good source for browsing PHP Book Reviews. PHP In Practice hasn't made the top 50 yet.
Rank this book if you've read it!
http://www.programmingbooks.org/PHP
There's a lot of horrible programming books out there. I wrote this web app to help programmers easily find the good ones. Basically programmers rank their top 5 books based on category(in this case, php books). It only works if people use it though, so rank the good programming books you've read!
no first-class functions (and no, create_function does not count)
Not all programming languages have and need this.
no usable object-model (check out response of developer below!)
self is bound at compile time. That's how it's defined. If you want to create active records like in Ruby just wait for PHP6 (currently the keyword is static).
problems with recursion
Infinite recursion is a problem in all programming languages - and a mistake. Several extensions help to avoid the segfault.
countless other horrible mis-designed "features" (not even starting on the security problems)
Check the dates of your bugs. For isset() use the magic method __isset(), the links in the second bug don't work, a static method doesn't have an instance and thus no $this. PHP 5 also warns about using a method as static without defining it as static.
Seems like you just want to use PHP as language X, which won't work and that's not PHPs fault. Use X and be happy.
that's a pretty strong argument. With all those facts you just pointed out, I guess I have no choice but to concede.
That's why Smart Developers (C) use http://cakephp.org/ ;)
So instead of pages of useless screenshots this book decided to go with content? What a gaping flaw! There are many books on PHP full of screenshots and little else if that's your thing. I see it as a bonus - if you want to see the screenshot you'll have to start doing some coding. Personally, I like PHP for a quick and dirty script, but would not recommend it for a project that was larger than around 3 lines of code.
Smart developers avoid PHP and if they are forced to use it they avoid PEAR and bloated PHP frameworks because they're so slow.
Can someone point me at a torrent of the eBook version?
(I kid, I kid)
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
Same sh*t another day.
Some uber programmers doens't like PHP because of someting else... Then start to bashing again and again
Php can't do this, can't do that. Php can't scale, Php was ugly, yada yada yada....
First purpose of Php was templating engine for HTML.
Other things comes afer.
Also, Zend try to add OOP. WHY? Why we need OOP aproach, run once scripts...
In php you cannot store objects in the Memory by default... (if you not use Memcaced/Seralize things)
I still don't get it. It was stateless universe. Evrything runs once and goes to ashes.
Whe we need all those OOP overload ?
Maybe to get more respect from other languages ?
Paaah...
Php language for who can barelly handling HTML.
It may not look nice. It may have some problems. May diturbing over obsssed engineers.
Of course, you may do more nice OOP thing in ruby, python of course you may do some hiber,uber,hypernate in JAVA.
And you cannot give
this much ability
under this cost (both cpu/ram)
and with this usability...
[My english is better than most other people's Turkish, so please point out mistakes politely. Thank you.]
He linked to them. Most of them are WONTFIXes right from PHP's bug tracking system. What the fuck more evidence do you require?
> self is bound at compile time
Wow. That alone is enough to just make me double and triple take with WTF's. The very construct that is supposed to represent late binding in every other language is deliberately and specifically early-bound in PHP. In an otherwise duck-typed language, even. It's like the PHP devs read a book on object oriented design and then designed the language specifically to defeat it.
Done with slashdot, done with nerds, getting a life.
Actually that's @{&$shudder->()} to you fella ;)
Done with slashdot, done with nerds, getting a life.
self:: in PHP is not the same as self. or this. in other languages. It seems like you're describing $this, which does refer to the current instance (you could call that late binding if you're into buzzwords).
"It does however have a good documentation. Without it though, programming PHP would be impossible. Try coding PHP without the documentation at hand." You're right, knowing the classes and libraries for different languages is always so easy..... you are just born with it right? What I'm trying to say is that any language, including php, can be manipulated to suit your needs with knowledge of the basic syntax. And like any language, when you want to take some shortcuts and make use of some helpful libraries (or php functions?), you will have to learn them.
I could not agree more. PHP has been a nighmare for me _because_ I've a strong programming background (>15y) in various other languages (C, perl, objc, c++, etc). Everything I could find in PHP was either "unconventional" (read: different for no good reason), buggy or simply horribly flawed. I wasted days understanding the (lack of) logic of the whole thing, not mentioning crashes and such.
I believe people hate php as much as they have experience in programming (and inversely, beginners usually enjoy it). Sure, we also have exceptions with large php projects that are well designed, and managed by good programmers.
As long as you don't want to give your code a good structure, use generic coding, rely on an efficient OO runtime, etc. php is okay. Not many tools are available to beginners ; perl, ruby and python are certainly much more demanding.
PHP5 in practice:
> ssh regular_joe@average_server
welcome to average_server regular_joe
> php -v
PHP version 4 motherfucker
Yet the world is full of programmers which abuse PHP to a level where you start to get the feeling that a complete rewrite of "the thing" is "the way to go"
so is it the language's fault or the programmers fault? you seem a bit confused.
Stop Computers/Cars Analogies on S
Nope. Just supressing unpleasant memories. Sorry for the inconsistency.
Explanation:
Smallish projects took me more time to complete then I imagined, almost every time. Now you could say "You suck at programming.", and thats fine with me as I don't give a fuck, but I've gone so far to expect the unexpected of PHP. And thats the languages fault.
The fact that larger projects took me almost forever to debug is of course the programmers fault. That almost every large project I ran into troubles while debugging was programmed in PHP and generally was regarded as high quality code does not increase my confidence in it.
LuckyStarr
(forgot password)
The rest of the observations are correct to the best of my knowledge and make PHP quite a horrible choice for all projects beyond a certain complexity threshold.
You are wrong because you obviously don't have experience in this area. PHP is quite capable for deploying large, enterprise-grade (not judged by the number of users using it, but by the quality of the processes involved and the business functionality it serves) software without a lot of headaches.
I treasure PHP and all of its shortcomings and inconsistencies. In time, these concerns will be addressed (some already have) and there will be less to complain about. PHP can be a blessing in disguise. Take a good MVC framework (CodeIgniter is one) and give PHP a fair shot -- you might be surprised to realize that its fun and equally capable.
For he today that sheds his blood with me shall be my brother.
I am so tired of the thousands and thousands of PHP "programming" books available. But I have not been able to find a really good PHP book that goes beyond just showing you the available syntax of PHP and instead describing different advanced and adequate (secure, crash-free, intelligent) way to do things. This is true for a lot of programming languages. I am looking for a book with "best practices" for the language in different areas. In the case of PHP it is quite trivial (compared to say, Java or C++) as the language scope is usually just databases (with some session logging information).
Ubuntu is an African word meaning 'I can't configure Debian'
I fail to see how one can treasure the shortcomings and inconsistencies of a development language (especially give that you expect them to be addressed). Usually a mature well organized language is a much more attractive basis for a development framework.
The shortcomings of PHP fall in three distinct areas:
- Language issues - these are the more fundamental complaints about the failed OOP implemementation, lack of modern mechanisms, core incosistencies. They indicate that PHP is not a good choice because of the most central choices the developers made. History tells us they will never go away. The developers simply don't want to change the way the language works and feels, most of the time citing the mantra of simplicity.
- Framework issues - these include the whole set of inconsistencies, failed implementations and huge limitations in the core function set. Take a look at the number of core functions in PHP and compare that with the number of methods available in
.NET's mscorlib and system assemblies alone (if we were to be fair we would have to include more assemblies in the list). By far PHP's the one with the thinner framework, yet PHP suffers from a lot of clutter and inconsistencies. Only the most recent additions actually use objects and, because of the first point, they are not very good. The PHP folks do not want to break backwards compatbility at all and this means they will have to carry all the namespace clutter and all the irreconcilable conventions with them with each version.
- Native or platform, which is better? - because of the nature of the PHP language (interpreted language, not compiled) there are considerable performance benefits when using platform code. The whole core framework is written in C because of this. Yet writing extensions in C is a tedious task that bears tremendous stability risks and this can be easily observed by the very reduced functionality offered by the core framework. At the same time this means that most extension frameworks (I include PEAR here) are written natively, which brings the disadvantage of using a poorly designed (see pt1) interpreted language, thus rendering these extension frameworks slower than if platform implemented. In contrast most of the
.NET framework (at least with mono) is natively implemented (even the c# compiler is written in c#).
You suggest that I should use a good MVC and give PHP a fair shot. First MVC is not necessarily what I would like to use. I find MVC to be overly simplistic. Then which of the multitude of MVC's out there will actually survive and will still be actively developed this time next year? Same goes for non-MVC web application frameworks out there. Yes, choice is a good thing, but some areas require standardization more than choice. A good web application framework is a very complex thing and learning more than one can be difficult. Having to learn a dozen is absurd.Also a web application framework is not the only thing missing in PHP. Admittedly most so-called "web application frameworks" actually include functionality outside the scope implied by the nomenclature. Some functionality though is hard to come by. Writing a self-hosted PHP web application is something I would not recommend to anyone, even though it's quite common in Perl, Python or
i don't think that is an associates link - i could be wrong. a lot of times, if i see a review in the 'mysterious future' i'll post an associates link. but it's just if i happen to catch it there -- which hasn't happened in a while. but i think various people do it when they get the opportunity. i don't know why people get so worked up about it.
i do know that it bothers some people (though i don't understand why) so i always mention that it is an associates link in the post and never post it anonymously.
but anyway - to get to your question specifically -- it's pretty easy to get first post if you are a subscriber and feel like taking time to wait for the story to go 'live'. i'd be interested in hearing why you think the practice is so offensive.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
Hehe maybe. But a good tradesman never blames his tools ;)