When is it safe to implement new PHP features?

[Man In Tan]

I was wondering: when is it safe to implement new PHP features? I can recompile PHP on my server anytime I want, to run new code locally, but when would it be safe to use new feature in code I'm distributing? About how long after a new version release of a free scripting language, such as PHP, can major web hosts be expected to update their compilers?

[justsomeguy]

It depends on the host, but you can check each host to figure out where they are in the release schedule.

[Man In Tan]

Oops, I wasn't very clear. When I said I could "run code locally", what I meant was that I can run code on my local server, where my site is hosted. Locally, as in on my site, as opposed to on other people's sites. I didn't mean I'm using an external web host, as my site doesn't get enough traffic to warrant that yet.I'm developing a forum, and I'm getting a lot closer to releasing it. I need to try to make it compatible with major web hosts, as that's what the people who'll be using my code will be using. I can't go around checking every major web host, that just isn't feasible. Is there a good rule of thumb for when using new features will be safe, or do I need to include two sets of code, and choose one to require() every time the script is run, using something such as version_compare()?

[justsomeguy]

I can't go around checking every major web host, that just isn't feasible.

Why? You could probably even use a script to do that, assuming the PHP version is included in the headers.

[boen_robot]

The only rule of thumb one can give without actually doing something like what justsomguy suggests is this - use the earliest function/class/feature/whatever that can do the job you want, stick to the earliest behaviour, and adjust for the newer ones. You'll achieve the greatest compatiblity, but at the price of degraded performance. So... you need to make a choice - performance or compatibility... you can't have both. Every "point" you give to one decreases the other.

[Man In Tan]

A script to check the headers? Wow, I should have thought of that. I forgot all about PHP's X-Powered-By header. But, I just tried looking at www.hostmonster.com's headers, and that one seems to be missing, and that's the first one I tried. I also tried http://www.hostmonster.com/index.php to make sure it uses PHP for its index page. Maybe it's a security thing. In their feature list, they say they offer PHP5, but they don't say which sub-version, so I can't even check by hand.Use the earliest feature for the job ... yeah, you're right. I got kind of exited about a new feature PHP is implementing, but I don't really NEED it. Things should work just fine using an older feature. Degraded performance doesn't sound good, though. Perhaps I should have a dual release. I could have one script for people with the latest PHP version, and another for people who have an older PHP version, or don't know their PHP version.Anyway, thank you both for the advice, I really appreciate it!

[jeffman]

I'm personally excited by 5.3's anonymous functions, but if I were writing a library, I'd use the more awkward create_function instead. Actually, I'm doing exactly that. Most annoying, but that's that.Dual release? If it makes something possible that otherwise is impossible, I can see it. If there's a work-around, I doubt I'd bother.

[justsomeguy]

The index.php file doesn't exist on that server, it comes up as a 404 and they handle 404 by loading their home page (index.html). I'm not even sure their main server uses PHP, it could be using Python or Perl or something else. They can set up so that PHP hides itself though, but you may have more luck if you check one of their client sites instead of their own site. You can also just ask each host individually what their upgrade policy is for PHP, it's probably not necessary to do that more than once just to get an idea about how often they upgrade in general.

[boen_robot]

I probably should've clarified that you get degraded performance IF you need to adjust for the newer behaviour OR if the new feature implements something that you're otherwise forced to do with a large PHP function. If it's just about using a feature that you can do without (or rather, if your app would traverse the same code paths for all versions without it) then there's not really a performance loss beyond the interals.In the case of... let's say anonymous functions, while AFAIK the new syntax is faster, it's still just "the exact same thing, but faster and fancier", so if that's the thing you fancy, then yes - you can do without it. If you try to optimize for using anonymous functions when they're avaiable and function_create() otherwise, you'll likely eliminate the performance benefit. A dual release could work if you can clearly isolate the version dependent features, but yeah... personally, I wouldn't bother either. I'd rather force users to get newer PHP versions.

[Man In Tan]

Annonomous functions don't do anything for me, but PHP 5.3.0's namespaces are a must-have, in my book. Not only can they reduce the likelihood of fatal name clashes when combining multiple projects, they can also be used to sort classes, constants, functions, and (I think) interfaces by developer, such as \domain\project\developer\function3(). I could fake a namespace by calling my function _domain_project_developer_function3(), so perhaps that's a better option, for compatibility.Serving the index page as the 404 page seems like it's just asking for trouble, to me. But I suppose it's not my server, and not my decision. All right, I'll see if I can find some sort of client index. I tried looking for update policies before, but no luck. Perhaps they have a support forum I could use to ask their staff about the update policy.Okay, got it. So it's the adjusting for the version of PHP running and using large compensating functions that degrades performance.Separating out the new features wouldn't be too hard. It's only namespaces and traits. The problem with forcing users to use a new version of PHP is that this is really up to their service provider. I suppose people can switch to a new provider, but the hassle of moving, and perhaps the price, would be a deterrent.

[boen_robot]

Hadn't seen traits before... and it officially becomes my favorite PHP 5.4 feature now, since I've needed something like it for some time now.While I can see how you can separate namespaced from non-namespaced code (you'd just do some string replacement from the non namespaced code to the fully qualified namespaced one), I'm not sure I can see how you'd be able to do the same for traits without introducing some issues caused by the separation.

[Man In Tan]

I know, right? I probably wouldn't upgrade right away (I am waiting for the stable version, though), if not for the new traits. With the new inclusion of namespaces, PHP 5.3.0 seems to cover everything else I could want, I just need to find the right manual page to tell me how to use it.As soon as I read about interfaces, I tried to use them to define methods that should exist in several classes (the way the new traits work), but that's not what they're for, and it caused a parsing error. Interfaces can only define abstract methods, so I don't see how they can be even remotely useful, except while debugging.I currently use an illogical inheritance hierarchy to get around the lack of traits, but I could replace it with a more logical inheritance hierarchy involving abstract classes with non-abstract methods. Since I keep all my namespaced code in a single file (well, two files, really), could just swap out the file with one that defines the classes a little differently for the more backwards-compatible version.

[justsomeguy]

If you're using these recent features, which I encourage you to, it may make sense to maintain two versions for the time being. It may be a pain to start with, but after a year or two when most hosts have upgraded to 5.4 then you'll already have an application ready to go with that version, and you can drop support for the older version. It can even be automated somewhat, you can detect the version and include either the newer or older files. The challenge there is having your main logic code work with either backend.

[Man In Tan]

All right, sounds like a plan.The back-end shouldn't be a big issue. My (flat file) database stores information in three, soon to be two, formats: comma-separated values (no issue here), and serialized objects. I can use str_replace() on the serialized string before entering it into the database, so it'll be the same for both versions. Because I sanitize my strings with htmlspecialchars(ENT_QUOTES), there shouldn't be any chance of O:13:"_my_class_name" (including quotes) showing up outside the place that needs to be replaced, so it it should be safe to not use a regular expression.Thank you all again for the help!