An Early Look At What's Coming In PHP V6 307
IndioMan writes "In this article, learn about the new PHP V6 features in detail. Learn how it is easier to use, more secure, and more suitable for internationalization. New PHP V6 features include improved support for Unicode, clean-up of several functions, improved extensions, engine additions, changes to OO functions, and PHP additions."
Update — May 7th at 16:47 GMT by SS: IBM seems to have removed the article linked in the summary. Here's a different yet related article about the future of PHP, but it's a year old.
So... (Score:5, Informative)
without wanting to be overly sarcastic..
What features are they gonne break this time?
Re:Hope it handles Search/Replace better (Score:4, Informative)
Re:question: (Score:4, Informative)
Yes :(
Re:So... (Score:5, Informative)
At my work we host and have build and maintain a little over 200 php websites. We host them all ourselves. ( the CMS that we use is build in PHP )
We earn money from both the hosting and the developing.
Many of our customers don't want to pay for the porting of their websites to PHP5, let alone PHP6. usually this requires upgrading the CMS as well, making modifications to custom extentions written by outsourcing partys, etc. All in all quite expensive for the site owner.
"Threatening" them with PHP4 server shutdowns only makes them go away to other hosting providers that will over PHP4 to them.
So we ended up virtualising all the PHP4 sites together with a good backup system and making our customers understand that we provide no warrenty anymore. We will help them when things blow up on an paid per hour basis.
Another problem is that we cannot reuse a lot of our code anymore now. Many of our new plugins require php5 so we have to modify them to make them php4 compatible again.
when php6 comes out we will have to support three different php versions... the horrors of that vision already scare me today..
Re:Object Oriented support in PHP (Score:3, Informative)
Re:One of these things is not like the OOthers (Score:5, Informative)
Or...
PHP:
$myarray[] = $myvalue;
Re:Finally (Score:2, Informative)
Interesting thought. Does anyone use PHP for anything other than its ubiquity?
Re:So... (Score:3, Informative)
I wish i was trolling, but trust me, i work for a company that hosts sites, and there is still plenty of php4 around. Most people don't mind the upgrading and staying up to date part so much. But they usually don't like the price that comes attached with it.
New to this version (Score:3, Informative)
Re:Hope it handles Search/Replace better (Score:3, Informative)
If you want to process large files (or any large chunks of data such as blob columns) in PHP without loading the entire file into memory, look into streams.
Re:My items to be fixed (Score:3, Informative)
PHP compiles regex's transparently automatically. If you've used a pattern recently, it will not reparse the statement.
Re:So, when will PHP 6 be released? (Score:3, Informative)
Re:My items to be fixed (Score:2, Informative)
Improve array speed (for simple arrays, use internally one simple C array/list - current days, any array is a map);
Try the SplFixedArray class [php.net]. The SPL data structures are much, much faster. [blueparabola.com] I actually rather like the "easy by default, fast when you need it" dichotomy.
Re:So... (Score:3, Informative)
You must be confused, are you thinking of Perl?
PHP has been VERY careful about breaking features, and have essentially openly mocked the people who suggest they "fix" PHP's functions by randomly swapping argument order on functions that have been working just fine for years.
The only thing I can think of they've broken is MAGIC_QUOTES and registered globals. Both are Very Bad Things that it was important they do away with. Any sane PHP code will react to their removal by simply removing a few chunks of good that were necessary to route around those features on servers that had them enabled.
Re:Finally (Score:3, Informative)
Broken Link in Summary (Score:5, Informative)
Re:So... (Score:3, Informative)
At least I ruined it by being informative. :P
Java applets coded back in 1996 still run [slashdot.org] in the newest JRE. Pretty impressive for the consumer/user, though it must be a nightmare to maintain.
I'm not aware of any huge changes to Apache Tomcat in the past few years - certainly nothing that required re-coding an entire website from scratch.
Re:Object Oriented support in PHP (Score:3, Informative)
How good is the object oriented support in PHP these days?
Everyone involved with PHP pretty openly admits that PHP5's OO model is a direct ripoff of Java, so inheritance, abstracts, interfaces, and access modifiers work pretty much the same way as they do in Java. If you like Java's OO, you should be fine with PHP5's.
Re:Finally (Score:4, Informative)
PHP is much, much closer to C than C++ with truckloads of STL piled on top. Ask a C programmer to comprehend that mess and you'll likely have a suicide on your hands. It is very un-C-like. The point is that the PHP syntax for arrays is very nearly identical in behavior and syntax to C, just with lots of extra functionality (variable length associative array). I never said that C++ couldn't do those things, but as far as I've seen, when you do it in C++, you're generally way off the deep end as far as being syntactically familiar to C programmers.
I guess what it comes down to is this: if you think templates are elegant, then we will never agree about what makes a good language design. From my perspective, templates are what happens when somebody forgets that we have a perfectly good C preprocessor and decides to reinvent the wheel with a clumsy syntax that doesn't provide anything more than what C preprocessing could already provide, wedging the concept into the language itself for no apparent reason. It is anathema. It is absolutely the antithesis of good language design.
As for OO in PHP, I don't see why you think dynamic typing decreases the value of object-oriented programming. If you really are mostly using the same code with different underlying types, then there's little point in doing OO, but in my experience, that's the exception rather than the rule. Most of the situations where I've used OO with polymorphism, I've had polymorphism, but the underlying implementation has differed substantially, and the only thing similar was the method name (and the general concept for what the function does).
Also, it is nice to use classes even when you don't need polymorphism. This reduces pollution of the global function namespace. It also makes it easy to create complex data structures that make life easier. (PHP doesn't have the notion of a struct, so you have to either use a class or an associative array.)
Finally PHP is still very much a typed language. It's not like there is no notion of types and everything is polymorphic with everything. The type of a variable is determined when the variable is assigned, and some types can be coerced into other types in certain use cases, but it isn't universal. I can't do if ($arrayA < $scalarB), for example. PHP even has the notion of casting to force type conversion just like you do in C. For example:
function myfunc($mynumber) {
...
$mynumber = (int)$mynumber;
}
Dynamic typing doesn't mean the types aren't there. If you call a method on an object that doesn't exist on that object, it is still an error. And so on. Dynamic typing just makes it a little easier to shoot yourself in the foot by not throwing up an error when you make the assignment or function call in the first place. :-)
Re:So, when will PHP 6 be released? (Score:1, Informative)
Re:question: (Score:2, Informative)
The problem with \ is that it has a well-established meaning outside of string literals in most languages of the curly braces family, to which PHP also belongs at least on the surface. And that meaning (escaping Unicode characters - at least in C++, Java, and C# are those I know, and there are probably more) has absolutely nothing to do with namespaces.
All your other examples are quite different - for example, there's no problem with Python using // for an operator, since it's decidedly not C'ish in appearance. VB has \ for integral division dating back to very early days of BASIC (before C, I believe). And so on.
Re:Finally (Score:3, Informative)
There's nothing preventing a native foreach notation built into the language instead of glued on. They just didn't do it that way, and they should have.
Sure. It's pretty easy. You just define two macros (e.g. BASE_TYPE and ARRAY_TYPE) and then #include a header.
#define BASE_TYPE uint64_t *
#define ARRAY_TYPE uint64_t_pointer
#include <CustomArray.h>
And in CustomArray.h>:
#define MAX_SIZE 32
class ARRAY_TYPE
{
BASE_TYPE[MAX_SIZE];
}
This is, of course, a trivial example. If you really want to get fancy, you can take advantage of token gluing.
#include <NewCustomArray.h>
And in that header:
#define MAX_SIZE 32
#define ARRAY_TYPE Array_##BASE_TYPE
#define ARRAY_PTRTYPENAME Array_##BASE_TYPE##_ptr
#define ARRAY_PTRTYPE Array_##BASE_TYPE *
class ARRAY_TYPE
{
BASE_TYPE[MAX_SIZE];
}
class ARRAY_PTRTYPENAME
{
ARRAY_PTRTYPE[MAX_SIZE];
}
And simultaneously create two classes, one for pointers to the type, one for the bare type. About the only place where this wouldn't work is if BASE_TYPE is "void" (since that makes no sense as a nonpointer type), and you can fix that with a simple preprocessor test.
Re:Finally (Score:3, Informative)
No, there's nothing preventing you from including that header file multiple times for different types. That's the beauty of token gluing. It concatenates the base type as part of the name of the derived array type, so you can create arbitrary numbers of them for arbitrary types. And unlike the template class, whenever you use the resulting type, it just looks like an ordinary C++ class instance with no need for template parameters. Thus, when you actually use the class, you just use "Array_int *foo" or whatever. Outside the syntax in the header file itself (which I'll admit isn't pretty), the usage syntax is cleaner this way.
Regarding the amount of code, in terms of file length, the C preprocessor version will generally be shorter in the long run. You only have to build the classes once, included from one file. Everywhere else, you just use an opaque forward reference to the class, e.g. "class Array_int;". The header for defining the class also is shorter; although you have the extra couple of macros up front, you save at least as many bytes over the course of the file by not having to litter it with template parameters everywhere. Ditto for the other source files.
And in terms of code generation, it's exactly the same amount of compiled code; the C++ compiler is generating separate classes under the hood for each of those base types. The only difference is that with preprocessor macros, you create the class explicitly up front with its own name so the instantiation syntax is cleaner.