PHP: A Few Changes To Go

I've been using PHP since 1998/99 and during that time, I've experimented with a lot of other languages every time I have come back to PHP.  Since PHP 5.3 there have been numerous changes that have greatly improved the language -- I am especially looking forward to changes in 5.5. PHP has grown as a language incredibly since 5.2 however, there are a few major changes that need to be addressed. It is time for PHP to pull up it's big-kid pants and grow-up as a language.

The list found below are a list of items which I would recommend considering for changes to the language. PHP is my preferred language; you will not find me bashing PHP nor hanging out with the Ruby on Rails fanboys who trash talk PHP and compare it to their framework as if it were an equal comparison [except for maybe the lack of a finally block -- which will be corrected in 5.5 (w00t!)]. I do have  a list of changes I feel would improve the language overall.

On to the list:

1. "$haystack, $needle" or "$needle, $haystack"  - pick one and make it consistent across the board. Most of the array functions use $needle, $haystack while string functions like, strstr or strpos are $haystack, $needle 
2. Pick a function naming method and stick with it - Underscore, all lower-and-crammed-together or camelCased. Examples:  in_array, isset, ReflectionParameter::getClass.
3. Replace "use " with "import" for namespaces - I have no real citation or legitimate reason for this I just really don't like the use keyword for namespace/class importing.  Use is used for too many thing within PHP plus I have proposed use for use at my next point. Wow, that was a lot of the word use.
4. Replace "use" with "has" for  traits - my biggest complaint is I feel like traits should be included on class declaration. (e.g. class Programmer extends Employee has Coder {...} ). Therein creates a separate problem where it leaves you needing to define Trait preference. I see no reason why these could not be stand-alone statements within the class itself. (e.g.
   
   class Programmer extends Employee [implements PersonInterface] has Coder
   {   
     Coder::getTitle as getJobTitle; 
     // or if you're hell-bent on the use keyword how-about...       
     use Coder::getTitle as getJobTitle; // not a bad option
     // or just as an interface declaration 
     public function getJobTitle as Coder::getTitle;
   }
   
5. Change String concatenation modifier from "." to "+"  - The plus-sign is generally used more often with String concatenation (as well as Math addition). Why do we need a separate modifier for String concat. I assume there was a reason this was done for a reason, I know Perl uses the dot for string concatenation.
6. Replace back-slash "\" with period "." for namespace separators - why would you want to use your escape modifier to separate namespace paths?

These are issues in the language that I feel should be resolved. Obviously these are not trivial adjustments to the language. These are API breaking "features" which is why I feel that if these changes are adopted they would need to go in at a major release such as PHP 6 or PHP 7.  Any one of these proposed changes would require a developer to completely "seek and refactor" projects moving to a major release adopting these changes. Therein lies the key to this proposal. While this sounds like it would be a problem and slow-down developers, unfortunately PHP developers or perhaps sysadmins have been slow to adopt new versions. That I'm not here to debate, but I will use that to assist my proposal. 

Based on a presentation by Nick Belhomme dated 28 January, 2012, PHP 5.2 was still head-and-shoulders above all other versions of PHP 5 - despite the fact that PHP 5.3 was released 30 June, 2009  ( citation ). Two and a half years later and 53.6% more people were using and "old" version. If the adoption rate is this slow it stands to reason that this would allow for developers to ease into the new major release of PHP. I don't want to treat this like the ultimate solution to my proposed adjustments, this solution comes with some risk. Look to python for an example, python 3 was release 3 December, 2008 and it still doesn't have a wide adoption rate. The PHP community as a whole would have to have complete (read-as: majority) buy-in to move forward with the language. 

Finally, as stated previously these are just some changes I would like to see in PHP, changes which I feel would improve the language as a whole. Improvements that might make the transition to PHP from another language slightly smoother, ease recall of syntax and simplify reading.  Changes of this kind are not without growing pains for all developers converting to a version supporting these changes but changes which make the language clean and more consistent.

.::.  DruiD628 .::.