PHP 5.3 Released
Sudheer writes "The PHP development team is proud to announce the immediate release of PHP 5.3.0. This release is a major improvement in the 5.X series, which includes a large number of new features and bug fixes. Some of the key new features include: namespaces, late static binding, closures, optional garbage collection for cyclic references, new extensions (like ext/phar, ext/intl and ext/fileinfo), over 140 bug fixes and much more."
Say what you will about PHP, but it puts food on my table and a good roof over my head. I have been clamoring for the new features in PHP 5.3.0 (closures, namespaces, they finally killed register_globals) and can't wait for the improvements coming in 6.
I truly appreciate the hard work of the PHP development team and the free language they have given us, congratulations on the new release.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
I don't think that's quite fair. I think if the functions, calling conventions and naming were regularized, it would be a reasonably decent scripting language. But it's because it suffers multiple personality disorder that it's a horrendous pain.
The world's burning. Moped Jesus spotted on I50. Details at 11.
GOTO has its uses. I never used it (as I prefer a more structured way to code), but critical mission error handling may take advantage of a more direct way to "jump". Anyway, one excepcional addition to the language is closures. Real anonymous functions were missing for a long time on the language, and it is great to have it now. Now it is only a matter of our customers' hosting providers to update their versions of PHP. Oh, well, considering most just migrated from PHP 4 to 5 (thanks to the EOL last year), it may take some time.
That's the shittiest login code I've ever seen, and friend, that's saying something.
I didn't said "exception handling", but "error handling", like linux kernel developers use.
Anyway, exceptions in languages like Java which enforces its treatment in compile time are more than just a "goto error handling". It all depends on the language you are using.
Uh, no.
Assuming that people running and maintaining the code are paying any attention, when 6.0 rolls out, those installations that have working code relying on features long-announced for deprecation that are removed in 6.0 will not upgrade to 6.0.
Major new interpreter versions enable new projects, and old projects can be migrated to them if there is a reason. But they aren't intended to be minor, backward compatible, performance improvement and bug fix releases -- that's why they are called major versions.
I think if the functions, calling conventions and naming were regularized
...and they removed the sigils, and removed the silent type coercion, and eliminated the "@" function prefix, and removed the "global" keyword, and removed the weird "list" lvalue function that looks-like-functional-pattern-matching-but-really-just-cosmetically, and fixed the pass-by-reference semantic...
But if you did all of these things, it really wouldn't be PHP anymore.
Don't blame me, I voted for Baltar.
__construct() is a magic method, just like __get(), __set(), __destruct(), __isset(), __toString(), so on and so forth. Magic methods are called without the programmer having to call them, under specific circumstances. In the case of __construct(), it's called when an object is instantiated. '__' defines a magic method and was chosen back in the day because PHP didn't have protected/private members and so the common practice was to prefix private/protected members with one underscore.
PHP was a solution to Perl, so -> is what Perl uses so that's what PHP uses.
The function naming is not so much an issue either. But what is frustrating is argument order. That's something that really needs to be revamped, backwards compatibility be damned.
I'm god, but it's a bit of a drag really...
In seriousness, I'm with the OP. I wish the ridiculous language evangelism would stop. In the end, people are just being short sighted and limiting the tools at their disposal.
Similes are like metaphors
Your comparison is off. Working at a company that has over 1000 java applications, I can tell you right now that you're so off. Simple fact, on a slower machine php will outshine java in terms of performance. On a enterprise powerhouse, the performance is about the same give or take based on how both are written. Its also not a fair comparison to compare java servlets to php. PHP to JSP is a fair comparison and your comparison would still be off base especially with the execution model. You cant compare PHP to Java on the same playing field as they are just that different.