PHP6 will bring new business to elite coders

[CrackFeed.Com]

With the release of PHP6 getting closer and closer, I am starting to get excited. For years I have been hired to fix a lot of crap code that was developed by self proclaimed "coders" that had little experience and little PHP knowlege. But with PHP6, I expect a lot of websites to crash upon moving to PHP6. No longer is PHP allowing for lazy coding, so coders wil actually have to take the time to code things the right way, the first time. Here are some examples:

<? = depreciated! Yep, short tags are almost out the door and you will be expected to use <?php. ASP tags will be gone entirely.

ereg = bye bye! I was a fan of ereg, but the ereg functions have been depreciated from quite some time and people still use them instead of preg.

Also gone, thankfully: Register Globals, Magic Quotes, GD1, Freetype1 and Safe Mode.

My gosh, this means people will actually have to register their variables properly, oh no! :lol:

Will be nice to see the fake experts getting new jobs and freeing up work for those that actually do the work correctly and see customers get what they paid done correctly. You know, the bums that charge $3 per hour and return crap code.

 

[Peter]

TBH it doesnt matter that register globals will be removed etc. If someone wants to be lazy they will be. It simply takes a few lines of code to replicate tje behaviour and some programmers will think it is a good idea to do so.

 

[CrackFeed.Com]

It is important that RG be removed. It is a serious security risk. As far as them thinking it is a good idea, doesn't make it a good idea and the customer paying the lazy coder is the one who gets hurt in the end and the coder gets hurt then because they just lost a potential recurring customer. I have seen recently a lot of scripts that need register globals and once RG is removed, those script will need to be modified to properly work again. You can't just call variables that have not been registered.

In other words, coders will need to give customers scripts that work, not just barely work.

 

[Peter]

In other words, coders will need to give customers scripts that work, not just barely work.

I am sorry but that just does not hold up. Every major version of PHP has broken scripts that worked in previous versions, many scripts had to be rewritten to work with PHP4, then again in PHP5 then again with PHP 5.2 and more recently PHP 5.3.

Just because a script relied upon functionality that eventually changed does not make it a bad script. We have all written scripts that needed to be adapted when newer versions of PHP came out. It is impossible to forsee changes that will be made in future.

Now fair enough people should not have relied on safe mode and register globals (and magic quotes for that matter) but when the developers were ramming it down peoples throats what do you expect.

Now safe mode itself was not an inherant problem. The problem with safe mode was more to do with people thinking they were safe when they were not. It is all good and well locking down PHP but this does not stop people exploiting vulnerabilities and permissions for scripts written in perl, java or any other language.

Magic quotes was also an extremely bad idea in hindsight. It did not take into consideration that some storage methods have different special characters than others. Also remember magic quotes was available in PHP 3, mysql_real_escape_string did not become available intil PHP 4.

Regarding register globals, I really do not know what the hell the PHP core developers were thinking of not sure what made them think it was a good idea but again this has been available since PHP 3 (or possibly earlier)

Here is a post posted by Rasmus Lerdorf himself trying to explain why register_globals was not a cause of security issues:

'[PHP-DOC] Re: [PHP-DEV] Security?' - MARC

Now would you call Rasmus a sloppy coder?

 

[CrackFeed.Com]

If a coder codes in a way that they avoid using depreciated functionalities, they won't have to alter the scripts to work with every new version. The majority of issues I see are headers already sent and undefined variables. These are there due to pure laziness, people think "hey, I can just turn off error reporting and all is fine. However, those notices are there for good reason as I am sure you are aware of.... and the way to avoiding them is simply taking the few extra minutes to avoid them. Look at the scripts on my site, I have error reporting on E_ALL right now and no notices or anything and it only took a few extra minutes to prevent those from showing.

I know that scripts coded for PHP3 will have issues and need updated. But my point here is about people still coding to php3 and 4 standards, getting paid to write scripts that will work long term but still coding with depreciated functionality like eregi(), knowing that eregi() will be gone soon. if I purchase a script, I expect it to run next year, not just this year... you know? The most common question i get before a deal is sealed witha customer is "Will my script be stable and secure?" and you just can't have stability while using depreciated functionality.

Safe mode really isn't a good example of my arguement and you are right, I put that as an example of changes to come, but no this has little to nothing to do with stability. As far as maci quotes, i do see your point.

Of course not, Rasmus is the PHP GOD. However I have observed that the majority of people still coding for use with register globals do not take the time to validate data either, they just code it up as fast as they can in order to please the customer in the mean time and move on to the next project. This may be a philosophical arguement, but that is just wrong and the customer should always get the best code for their dollar.

Now if register globals automagically cleaned the data, I would love it, which I believe was the whole point of magic quotes, a desperate attempt to fix a major F-up on Zend's part.

---------- Post added at 08:38 PM ---------- Previous post was at 08:29 PM ----------

Here is an example of the crappiness of relying on register globals when selling scripts to clients.

<?php
if (!$action) {
	echo 'Welcome to this site! Choose an action: <a href="example.php?action=foo">foo</a> <a href="example.php?action=bar">bar</a>';
	exit;
} else {
	if($action == 'foo') {
		echo 'foo';
		exit;
	} elseif($action == 'bar') {
		echo 'bar';
		exit;
	}
}
?>

The above code will always show Welcome to this site! Choose an action: <a href="example.php?action=foo">foo</a> <a href="example.php?action=bar">bar</a> no matter the user's choice and also show Notices for an undefined variable. The below code will do what the client purchased the script to do and only take 10 seconds more to code:

<?php
if (empty($_GET['action'])) {
	echo 'Welcome to this site! Choose an action: <a href="example.php?action=foo">foo</a> <a href="example.php?action=bar">bar</a>';
	exit;
} else {
        $action = strip_tags($_GET['action']);
	if($action == 'foo') {
		echo 'foo';
		exit;
	} elseif($action == 'bar') {
		echo 'bar';
		exit;
	}
}
?>

My entire arguement is over the client getting the best quality possible at the time of purchase, not that in 10 years he will have to get touch up work done, that is a given.

"It is impossible to forsee changes that will be made in future."

No, Zend always gives a heads up to changes we can expect within the next year.

 

[dezinerite]

Very interesting news. I'm currently self-learning PHP and there's no better time!

 

[Peter]

If a coder codes in a way that they avoid using depreciated functionalities, they won't have to alter the scripts to work with every new version. The majority of issues I see are headers already sent and undefined variables. These are there due to pure laziness, people think "hey, I can just turn off error reporting and all is fine. However, those notices are there for good reason as I am sure you are aware of.... and the way to avoiding them is simply taking the few extra minutes to avoid them. Look at the scripts on my site, I have error reporting on E_ALL right now and no notices or anything and it only took a few extra minutes to prevent those from showing.

I do agree with coding using E_ALL error reporting (also remember to to use E_STRICT if using PHP5 or greater). However some functionality has only become deprecated in PHP 5 or even PHP 5.3 how do you expect a programmer to have known it was to be depacated prior to this?

I know that scripts coded for PHP3 will have issues and need updated. But my point here is about people still coding to php3 and 4 standards, getting paid to write scripts that will work long term but still coding with depreciated functionality like eregi(), knowing that eregi() will be gone soon. if I purchase a script, I expect it to run next year, not just this year... you know? The most common question i get before a deal is sealed witha customer is "Will my script be stable and secure?" and you just can't have stability while using depreciated functionality.

Easy to say but harder to implement. If you have a large scale application it is not always that easy to make changes. You have to ensure that all scripts work fully in the bulk of setups this involves a lot of testing. Scripts made prior to PHP5 also did not have a good way to use OOP. Without the ability of proper code reuse it takes a lot of extra work gaving to find all instances of specific code to change it. Remember in PHP 4 OOP was not real OOP.

Of course not, Rasmus is the PHP GOD. However I have observed that the majority of people still coding for use with register globals do not take the time to validate data either, they just code it up as fast as they can in order to please the customer in the mean time and move on to the next project. This may be a philosophical arguement, but that is just wrong and the customer should always get the best code for their dollar.

To be honest this is not always the programmers fault. Customers have a complete lack of understanding of what is involved. Many simply want the job done as quickly and as cheaply as possible. Even the most experienced of programmers come across this. The choice they face is to either drop the job or cut corners.

Now if register globals automagically cleaned the data, I would love it, which I believe was the whole point of magic quotes, a desperate attempt to fix a major F-up on Zend's part.

Magic Quotes does not attempt to clean data. Magic Quotes attempts to make the data safe by escaping special characters however is an impossible task to truly carry out. mySQL for example has different escape character than msSQL. This argument is also not confined to databases it holds true for any method of storage.

Also how do you work out that magic quotes was an attempt to resolve a mess that Zend caused? I suggest you look more at what the Zend engine is and how it interacts with PHP. Magic quotes has nothing to do with the Zend engine. Also it is not the job of PHP to pre empt what the user is trying to do. If this is what you want go for Ruby On Rails.

---------- Post added at 08:38 PM ---------- Previous post was at 08:29 PM ----------

[/COLOR]Here is an example of the crappiness of relying on register globals when selling scripts to clients.

<?php
if (!$action) {
	echo 'Welcome to this site! Choose an action: <a href="example.php?action=foo">foo</a> <a href="example.php?action=bar">bar</a>';
	exit;
} else {
	if($action == 'foo') {
		echo 'foo';
		exit;
	} elseif($action == 'bar') {
		echo 'bar';
		exit;
	}
}
?>

The above code will always show Welcome to this site! Choose an action: <a href="example.php?action=foo">foo</a> <a href="example.php?action=bar">bar</a> no matter the user's choice and also show Notices for an undefined variable. The below code will do what the client purchased the script to do and only take 10 seconds more to code:

<?php
if (!empty($_POST['action'])) {
	echo 'Welcome to this site! Choose an action: <a href="example.php?action=foo">foo</a> <a href="example.php?action=bar">bar</a>';
	exit;
} else {
	if($action == 'foo') {
		echo 'foo';
		exit;
	} elseif($action == 'bar') {
		echo 'bar';
		exit;
	}
}
?>

Now to be honest that is not necessarily the best option. What if they go too example.php?action=bugger. Depending on what you are doing your script could fail just as badly. You should always have a fallback position in case the input is not as expected.

No, Zend always gives a heads up to changes we can expect within the next year.

Now that is not quite true. No functionality of PHP (or any other software or languages) can be relied upon until it is released out of beta. Oh and on a side point Zend do not release PHP.

Look at the development of PHP 5. GOTO was only announced within a couple of months (if not less) of the PHP 5.3 being released from beta. And while I am on that subjust, you are stating that magic quotes and register globals make coders lazy. Well goto is a much worse prospect that will help make the code completely unmanageable and help introduce bugs into software. Most programmers in other languages have learnt that goto is a very bad idea and here PHP has decided to introduce it. Expect goto to be gone by PHP7

 

[Kate]

I have seen bad coding in all languages including stricter ones.
Even if a lazy programmer can build a functional application, does not mean it is optimal and secure.
Web applications are prone to security risks like SQL injection attacks if you don't know what you're doing.
I have also seen many LAMP scripts that use mySQL tables with no indices or a poor relational model. Of course as the database grows, response times increase as well and the scripts may turn out to be non-scalable.

 

[NetworkProblems]

Interesting news, thanks! Too bad magic quotes has to go... probably there were some problems with it. It will still take a while for it propagate.

 

[CrackFeed.Com]

From what I have read, GOTO was to be gone in PHP6. Zend Technologies was who I was refering to, a company founded by the guys that rewrote the php parser into PHP3, not the engine itself, just the company that I blame. The examples I gave were just quick things I tossed up, wasn't postign a "complete work", just showing an example of the point I was making. I would do something more like:

<?php
if (!function_exists('redirect')) {
	function redirect($url){
      		echo '<script type="text/javascript">';
      		echo 'window.location.href="'.$url.'";';
      		echo '</script>';
      		echo '<noscript>';
      		echo '<meta http-equiv="refresh" content="0;url='.$url.'" />';
      		echo '</noscript>';
	}
}
if (!empty($_POST['action'])) {
	echo 'Welcome to this site! Choose an action: <a href="example.php?action=foo">foo</a> <a href="example.php?action=bar">bar</a>';
	exit;
} else {
	if($action == 'foo') {
		echo 'foo';
		exit;
	} elseif($action == 'bar') {
		echo 'bar';
		exit;
	} else {
		redirect('file.php');
	}
}
?>

---------- Post added at 12:55 AM ---------- Previous post was at 12:49 AM ----------

I have seen bad coding in all languages including stricter ones.
Even if a lazy programmer can build a functional application, does not mean it is optimal and secure.
Web applications are prone to security risks like SQL injection attacks if you don't know what you're doing.
I have also seen many LAMP scripts that use mySQL tables with no indices or a poor relational model. Of course as the database grows, response times increase as well and the scripts may turn out to be non-scalable.

You are quite right, coders need to not just focus on a working product, but also that the product, data and the server hosting it will remain safe and functioning efficiently. The database setup absolutely needs as much attention as the actual scripts, especially for databases that get a lot of queries constantly. A nice my.cnf config goes a long way too, some people setup their my.cnf with too high of memory settings making it pretty inefficient so it is good to define the parameters specifically to your system's hardware configuration and not because some joe-shmoe from a baord said it worked for them.

---------- Post added at 12:57 AM ---------- Previous post was at 12:55 AM ----------

Very interesting news. I'm currently self-learning PHP and there's no better time!

Best of luck, PHP is a great tool that I am sure you will enjoy working with! These are exciting times for PHP, imo. Every since PHP4 brought out object orientation I have not been able to stop coding... sometimes even forget to sleep! :lol:

 

[Peter]

From what I have read, GOTO was to be gone in PHP6.

TBH I have not seen any news on that but I have not been following the PHP 6 development fully.

However if that is the case, does that not tell you a bit about the development process of PHP. They spent months convincing people why GOTO was not a bad idea and how if used correctly is very powerfull, then on the next major version removing it.

Many people will have already created scripts on the basis of what the PHP core developers have stating now only to find the functionality soon to be removed. Now under your definition they are bad programmers yet they are just takig the core developers at their word.

I personally have not touched goto with a barge pole.

---------- Post added at 08:00 AM ---------- Previous post was at 07:57 AM ----------

Best of luck, PHP is a great tool that I am sure you will enjoy working with! These are exciting times for PHP, imo. Every since PHP5 brought out object orientation I have not been able to stop coding... sometimes even forget to sleep! :lol:

OOP has been available since PHP 4 not PHP 5. There was a problem however with the implementation of OOP within PHP 4. Objects for example were not real objects in fact they were C arrays. The way objects behave (except for the newer features such as scope etc) is the same as they tried to ensure backwards compatibility as much as possible.

 

[CrackFeed.Com]

I personally have not touched goto with a barge pole.

True that

Opps meant to put 4, now I look a bit daft (corrected above). I also saw that VAR will be aliasing PUBLIC from now on in PHP6, I think that is a good step as that a good majority of scripts use VAR right now.