In a new blog post on PHPClasses.org today Manuel Lemos has gathered together some of the things that PHP doesn't have (yet). Most of them are things that developers have expressed a desire for in the core and either have yet to make it into a RFC or are still just being implemented in "userland" code.

The PHP development process is still a bit frustrating. Many developers hoped that PHP had certain features but those are still missing due to several reasons. One way to see those features happen is to write code to implement the features and then submit the code to the PHP core. However that is not a guaranteed process. Even if you provide the necessary code, other developers may object to the addition of those features and the effort is wasted.

Among the things he lists as features that are desired but not implemented yet are things like:

• Aspect oriented programming
• Annotations
• Class generics
• Introspection of private variables and functions
• Named parameters

There's a summary of each of the features mentioned and in some cases links to RFCs that presented the same ideas. If you're interested in presenting your own ideas to the PHP project for inclusion, you can "demystify" the RFC process by checking out this post from Chris Jones with lots of good suggestions and the flow of how the process (usually) works.

For anyone that's wondered how some of the features they use every day get into the PHP language, Chris Jones has written up a post making the RFC (Request for Comments) process they follow a bit more transparent for the average developer.

The PHP RFC process has been in place for a while, and users new to core PHP development are starting to use RFCs to propose desirable features. Here are some personal observations and suggestions that show how I have seen feature acceptance and the (newish) RFC process work in practice. These notes augment the steps in How To Create an RFC. I hope they help set expectations about the PHP RFC process and feature acceptance in the PHP language.

He lists the steps in the process from start to finish including things like:

• Avoid presenting an RFC idea to the "internals" mail list with email that begins "I don't know much about ... but ...". Do some research first.
• Your RFC should talk about all PHP areas that will be affected: php.ini, different SAPIs, engine, extensions, etc. List similar features. List similar features in other languages. Link to references. Give an estimate of the actual positive impact to user code.
• If you do have an implementation, make it clear whether the implementation is a simple prototype or is expected to be the final code. This is specially important during the vote.
• There is no need to respond to every discussion email individually. You should batch up your responses and manage the discussion intelligently.
• With long, fragmented discussions, not everyone will read every email. Update the RFC at regular intervals, and let people know what has changed.
• Some areas of PHP are complex or niche. Sometimes feature suggestions will be greeted by an apparent lack of interest. Don't be discouraged. This just means you need to take a stronger leadership role, and also prove your credentials by first working on the existing code base.
• During the voting period, it is common for people to continue mail list discussion. You may need to halt the vote and address any issues.

Obviously, there's a lot more to it than that - his post does a great job of letting you know what to expect and includes useful tips on helping you get your idea across.

With some of the recent talk about the consistency of naming methods in PHP (or lack thereof) Phil Sturgeon has put together some ideas about why this (and unicode) changes aren't happing in the language.

PHP is well known for having an inconsistent API when it comes to PHP functions. Anyone with an anti-PHP point of view will use this as one of their top 3 arguments for why PHP sucks, while most PHP developers will point out that they don't really care. [...] Another big thing that anti-PHP folks laugh about is the lack of scalar objects, so instead of $string->length() you have to do strlen($string). ANOTHER thing that people often joke about is how PHP 6.0 just never happened, because the team were trying to bake in Unicode support but just came across so many issues that it never happened.

He shares an "obvious answer" to the problems and shares a theory as to why it's not happening - that no one is really working on out (outisde of this POC) and some of the handling with the recent property accessors RFC. He finishes off the post with three more points, all related to the results of the voting - little points seem to get voted in easier, the representation of developers in the process and that at least one of the "no" votes had to do with not wanting to maintain the results.

Making changes to this language should not be blocked just because a quiet minority of the core team don't like the idea of being asked to do stuff.

Be sure to check out the comments on the post - there's lots of them, so be sure you have some good time to read.

There's been a lot of chatter about a recent RFC from Pádraic Brady on the php.internals maling list - his proposal to add native escaping to the PHP core. He shares some of his own thoughts about the proposal in a new post to his site.

A short time ago today, I submitted a PHP RFC for discussion which proposes adding an SPL Escaper class and, quite possibly, a related set of functions dedicated to escaping data for output to HTML/XML to PHP: https://wiki.php.net/rfc/escaper. The RFC itself should be a good read if you want to understand why I'm proposing this but the basics are quite simple. Cross-Site Scripting (XSS) is one of the two most common security vulnerabilities in web applications - the other being SQL Injection. Despite this, PHP's offering of escaping functions is extremely limited.

He talks about what problems the proposed solution solves and how it could help protect PHP programmers more effectively than the more complicated methods they have to go through now. If you're interested in reading the conversations so far, you can start here and walk through the messages.

Miro Svrtan has a new post today proposing something that could be added to help handle bad method calls in PHP apps - using the BadMethodCallException (pre-existing) instead of throwing fatal errors.

Using getter method that is not implemented will get you fatal error saying how undefined method is called and request will stop. [...] On the other hand if you would use public property all you would get is a notice saying how this property does not exist and rest of request would be completed. [...] I know that this is due to dynamic typing behavior of PHP and no I am not suggesting raising a notice if undefined method gets called but since 5.1.0 there is a BadMethodCallException class which would be perfect for this situation.

There's been other people that have proposed the same idea as a bug, but nothing formal has been submitted as an RFC to make the change. Miro is looking for feedback to find if others would be interested in this feature and want to make the proposal (leave comments here).

In this recent post to his site Sherif Ramadan looks at a proposal that's currently under view (RFC) to add the "finally" keyword to PHP.

It's quite possible that PHP may finally be getting the addition of the finally block in its try/catch block. [...] It also solves a simple, but overlooked problem for the developer. With finally we offer the user-space code a chance to do any clean up work that may be necessary after a try block has terminated execution and with clear semantics.

He includes a use case for this feature - an example showing exception handling on multiple levels and writing to log files when the cleanup of the exception is finished (without the potential for another method to trigger the exception itself). "Finally" allows you to take this logic out of the exception handling and put it at the end, removing the possibility of it triggering an exception for the wrong reason. There's a few other examples showing some other quirks with its usage - like calling die will not make it end up in the "finally".

Anthony Ferarra has a new post looking at using generators in your code (as recently proposed for addition in PHP's core (Possibly for 5.5.0). While I believe that this is a great tool, it appears that many PHP developers aren't familiar with the concept of generators. So I thought I would take a little time and explain some of how it works, and how it can be used to greatly simplify code.

He explains the concept of "generators" as an easier way to implement iterators. In his example he shows how to refactor is file handling iterator to replace it with generator functionality. It uses a new keyword, "yield", to return a Generator instance that can then can be used much like the file iterator without the need for all of the code to create the iterator itself. His more complex example shows how to replace an ArrayObject instance by a little trick inside its "getIterator" method.

Nikita Popov has looked ahead to the future of PHP in a new post to his blog , thinking about what PHP 5.5 might be like and what features could be included.

PHP 5.4 was released just four months ago, so it probably is a bit too early to look at the next PHP version. Still I'd like to give all the people who aren't following the internals mailing list a small sneak peak at what PHP 5.5 might look like.

He's looking at the proposed functionality, not finalized features, so some of it might not make it in. He mentions things like:

• Windows XP and 2003 support dropped
• boolval()
• hash_pbkdf2()
• array_column()
• Constant dereferencing
• Parameter skipping
• Scalar typehinting

On the PHPClasses.org site today they've posted their latest episode of the "Lately in PHP" Podcast, "Will it ever Matter if PHP Sucks?"

Once in a while we see fans of other languages writing long articles on why PHP sucks and you should not use it. But will that ever matter? That is one of the main topics discussed by Manuel Lemos and Ernani Joppert in the episode 23 of the Lately in PHP podcast, for the first time also recorded in video using Google Hangouts On Air.

They also talk about some of the recent proposals for PHP itself and the buzz surrounding the "HTTP 2.0" protocol that's been proposed. You can listen to this latest episode either via the in-page player, by downloading the mp3 or subscribing to their feed. Since they used the Google Hangouts to record the session, you can also watch the video.

Anthony Ferrara has a new article posted to his site today about parameter typecasting and the discussions that have been happening about it on the PHP "internals" mailing list.

As any of you who follow the PHP internals list know, scalar type hinting has been a hot topic as of late. You'll also know that I've submitted two new RFC (Request For Comment) proposals for inclusion of two new major features in the PHP language. I figured it was worth going into both RFCs and patches a little deeper, explain my rationale and (hopefully) garner some more visibility of the proposals.

He shares the details of the two main RFCs that are proposed right now - parameter type casting hints and object scalar casting magic methods (both with code examples). Right now, they're only in the patch stage and there's talk of improving the current casting functionality of PHP before something like one of these goes into place.