How will PHP 5.3 affect your application?

[Michael Morris]

whenever new version of current technology , people adopt it as soon as possible, but what about old customers and all the servers in this case are using old PHP versions ,

immediaate shift of , such kind, is some sort of risky step.

Forget 'em. If people like that are allowed to control the world we'd still be computing on Commodore 64's

[Hammer65]

Traits would definitely be more useful than namespaces to me at the moment. My applications consist entirely of classes I've written myself, so there aren't any naming conflicts. I do often write classes that have several methods in common and copy-and-paste code from an old class into a newer one.

You can still get naming conflicts with classes, it's just less likely. You could also get naming collisions with namespaces, but even less likely.

[logic_earth]

Actually, the windows version of PHP has to convert it on the fly. DIRECTORY_SEPERATOR is slightly faster since it skips the need for the string replace. Besides, for some stupid reason I like the appearance of the syntax.

Early optimization for something that really doesn't need to be optimized. If you are concern with speed then you should profile your code and work on the spots that really need to be optimized.

Either way HTTP will slow the application down.

Also I'll like to see the reference to "windows version of PHP has to convert it on the fly"

Not using the DS constant is averagely faster then using it: (Using though the CLI.)
Going though Apache the speed stayed consistent while using the DS constant was sometimes faster sometimes slower.

<?php

$l = 1000;

$t1 = microtime( true );

for ( $i = 0; $i < $l; $i++ ) {
    file_get_contents( 'C:/Users/Logic/Documents/d.php' );
}

$t2 = microtime( true );

var_dump( $t2 - $t1 );

$t1 = microtime( true );

for ( $i = 0; $i < $l; $i++ ) {
    file_get_contents( 'C:' . DIRECTORY_SEPARATOR . 'Users ' . DIRECTORY_SEPARATOR . 'Logic' . DIRECTORY_SEPARATOR . 'Documents' . DIRECTORY_SEPARATOR .'d.php' );
}

$t2 = microtime( true );

var_dump( $t2 - $t1 )

[Chris Corbyn]

Using ::function actually is the way you access the global namespace in C++.

Fail!

[dreamscape]

And that's sad; especially Traits would seem thoroughly awesome.

Couldn't agree more... anything that puts us a few steps closer to native AOP support gets a big thumbs up from me.

[ruby-lang]

Kudos to the PHP dev team. If they had waited for PHP 6 to introduce these changes, they would have run the risk of losing a lot of mindshare to Python and Ruby.

As a plus, getting namespaces now means less work to port things over to 6.0 when it's out.

@logic_earth:
I may be mistaken, but I think that outside the command line Windows XP/Vista is equally happy with forward or backslashes, an addition to the NT kernel to make it POSIX-compliant. That would explain your results.

[fatnewt]

I'm happy about it. It'll be quite a while before I can use it on any client sites, but for my own applications where I control the server I'm looking forward to getting started with it.

[Czaries]

Kudos to the PHP dev team. If they had waited for PHP 6 to introduce these changes, they would have run the risk of losing a lot of mindshare to Python and Ruby.

That's an interesting point. I never thought about that as being the reason to these early introductions to such significant new features, but it certainly makes sense, especially with all the buzz about Rails and all it's advanced OOP features. If that's the reason, then kudos to the PHP team for recognizing it and pushing forward.

[logic_earth]

...buzz about Rails and all it's advanced OOP features....

*cough* That would be Ruby, Rails just provides more functionality.

[Czaries]

*cough* That would be Ruby, Rails just provides more functionality.

Hah yeah... that's what I meant

[33degrees]

I never thought about that as being the reason to these early introductions to such significant new features, but it certainly makes sense, especially with all the buzz about Rails and all it's advanced OOP features. If that's the reason, then kudos to the PHP team for recognizing it and pushing forward.

I'm not sure that's their goal; I think it has more to do with getting hosting companies on board quickly and avoiding a repeat of php5's uptake problem than a concerted effort to win back some of the mind share that has been lost to RoR. Fundamentally, PHP's development process is way too conservative for the language to ever gain the types of features that make ruby or python attractive.

[ruby-lang]

If what I heard about Traits and Closures making it into version 6 is right, then PHP is less conservative than Java. It also doesn't need all the metaprogramming tricks other languages need to create domain-specific languages, because hey, it's already a DSL for web programming!

I just wish they'd integrate prepared statements from PEAR into the core libraries. Concatenating SQL with user input is Just Plain Wrong, no matter how many escaping and encoding functions it goes through.

[Hammer65]

If what I heard about Traits and Closures making it into version 6 is right, then PHP is less conservative than Java. It also doesn't need all the metaprogramming tricks other languages need to create domain-specific languages, because hey, it's already a DSL for web programming!

I just wish they'd integrate prepared statements from PEAR into the core libraries. Concatenating SQL with user input is Just Plain Wrong, no matter how many escaping and encoding functions it goes through.

You do know that MySQLi does prepared statements do you not? That has been in 5.x from the start. The problem is, that there aren't enough books and tutorial material available for using prepared statements. In fact I would say that instructional material and documentation for PHP has lagged far worse than the adoption of PHP 5.

[auricle]

You do know that MySQLi does prepared statements do you not? That has been in 5.x from the start.

PDO too

The problem is, that there aren't enough books and tutorial material available for using prepared statements.

Err... with PDO I worked it out from the examples. Never particularly had problems with prepared statements. (Other things sure, like PDO::FETCH_CLASS and idiosyncracies of SQLite versions.)

[Hammer65]

PDO too

Err... with PDO I worked it out from the examples. Never particularly had problems with prepared statements. (Other things sure, like PDO::FETCH_CLASS and idiosyncracies of SQLite versions.)

My point was, not that I was having difficulty understanding or using them, but that prepared statements are not widely used, because the tutorial material is not widely available. Hence the reason you still see so many new coders using the OLD MySQL extension. I can't remember the last time a new coder came here asking about help with prepared statements in PHP. They haven't caught on because despite various people here recommending them, there isn't enough material on them. A new coder is less likely to use an abstraction, and more likely to use the built-in functions to learn.

[ruby-lang]

You do know that MySQLi does prepared statements do you not?

Actually, no, I couldn't find anything about it or PDO when I checked, 7 or 8 months ago. Thanks for showing me the light.

[Czaries]

I have been using PDO exclusively since PHP 5.1 (1st stable branch of PHP5), and it has been wonderful for my sanity. No more worrying about SQL injection or "Did I escape _ALL_ the input data? Am I really sure I got everything?".

I do agree though that there are not nearly enough tutorials that involve the use of PDO or even ones that involve proper escaping/sanitizing of user input. That momentum is starting to change though as PHP gets more and more advanced features. I look forward to the future.

[Hammer65]

"Did I escape _ALL_ the input data? Am I really sure I got everything?".

That's one thing that I don't understand. I've done plenty of complex projects and though I recognize that it can be hard at times to keep everything in your head, I really don't see how, while coding something, that you could forget to escape input, unless you had a 50 field form you were working with and you were writing 50 lines of escaping, rather than looping through input in a function and doing escaping.

[33degrees]

If what I heard about Traits and Closures making it into version 6 is right, then PHP is less conservative than Java. It also doesn't need all the metaprogramming tricks other languages need to create domain-specific languages, because hey, it's already a DSL for web programming!

That's a really big if: I know these things have been discussed, but have not seen any indication that they're seriously being considered for inclusion. I personally highly doubt they'll make it into the language, although I would love to be proved wrong. BTW, closures are coming to java, and while java's pace of development may be slow, it's further ahead in the race as it is.

[dwayne12]

I think it's fairly safe to say that most of my applications won't be affected by PHP 5.3 changes. Although my newest PHP project will most definitely be affected, but I've already started making changes to my code and updating isn't that hard at all.

I welcome this new version, but I am also now wondering what will PHP 6 have that PHP 5.3 doesn't have?

[SpacePhoenix]

With all the changes in PHP 5.3 how badly will PEAR Classes be broken by the changes?

[33degrees]

With all the changes in PHP 5.3 how badly will PEAR Classes be broken by the changes?

I don't think any existing code will be broken by 5.3; they're surely keeping all the backwards compatibility breaks for 6.0

[ahundiak]

I don't think any existing code will be broken by 5.3; they're surely keeping all the backwards compatibility breaks for 6.0

I'm sure thats the plan but has anyone here every moved a non-trivial app from 5.0 to 5.1 to 5.2 without having to make some changes? Usually the changes are small but I have always needed to do some tweaking to get things working.

[brandlover.vn]

Fatal error: Class 'NS1' not found in namespace1.php on line 15

phpinfo(1);
function __autoload( $classname ) {
       //$classname = strtolower( $classname );
       $classname = str_replace( '::', DIRECTORY_SEPARATOR, $classname );
       require_once( dirname( __FILE__ ) . '/' . $classname . '.php' );
}
//use NS1;
 
NS1::test();

NS1.php

<?php
namespace NS1;
 
function test()
{
    echo '__ALL__';
}

[logic_earth]

Off Topic:

I'm curious why in the above image you censored data that isn't sensitive...not even remotely sensitive...
If you hid anything should have been "Windows NT" + "5.1 build 2600" as this tells me you are running the first release of Windows XP. But you hid the computer name and the drive letter the php.ini file is on...hmmm

Heh and you left C:\WINDOWS clear...so very curious why you censored portions of it now