I'm pleased to release our first ever round table, where we place a group of developers in a locked room (not really), and ask them to debate one another on a single topic. In this first entry, we discuss exceptions and flow control.

The opinions vary among the group as to what exceptions should be used for (even outside of the flow control topic). Opinions shared are things like:

• Exceptions are situations in your code that you should never reach
• Errors cause Failures and are propagated, via Exceptions.
• So, essentially, exceptions are an "abstraction" purely to model the abnormality.
• Personally, I envision exceptions more as "objections."
• Exceptions like this should be caught at some point and transformed into a friendly message to the user.

There's lots more than this in the full discussion so head over and read it all - there's definitely some good points made.

Being totally out of ideas, we turned things over to our legions of fans who joined us on IRC. Lots of interesting questions, and people learned what Ed thought was horseshit.

As you can imagine, there's lots of topics covered including some discussion of PHP IDEs, if PHP has reached its limit and liberal versus conservative programmers. You can listen to this latest episode either through the in-page player, by downloading the mp3 or by subscribing to their feed.

We're back for an "IRL" episode, with Zack Kitzmiller, John Crepezzi and Anthony Ferrera, discussing PHP 5.5 and the new features it will bring.

You can listen to this latest episode through the in-page player, by downloading the mp3 or by subscribing to their feed to get the latest as they're released.

An important discussion on the PHP "internals" development mailing list is taking place. It's one that you should take some note of. It concerns the next step in transitioning PHP applications away from the very old mysql extension and towards adopting the much better mysqli extension or PDO_MYSQL driver for PDO. This would allow the mysql extension to, at some as-yet undetermined time in the future, be removed.

He links to a RFC that's been posted to help promote and push this idea forward with mentions of the "carrot" and "stick" methods for pushing users towards mysqli.

As always, there is a lot of guesswork going on as to what MySQL APIs are in current use by PHP applications, how those applications are deployed, and what their upgrade cycle is. [...] I want to repeat that no time frame for the eventual removal of the mysql extension is set. I expect it to be some years away.

I'm going to throw out here some potential advanced skills from off the top of my head - not at all a complete list.... PHP objects? PHP regular expressions? Frameworks? Security measures? Ability to use PHP to do cool things like recursive node walking of XML files? Use of third party libraries? Or would you add something else entirely? Just curious, because I'm looking for work and want to know if I can reasonably bill myself as having advanced PHP skills. Thanks for the input!

Responses cover a wide range of topics including:

• the Zend Certification(s)
• Clean, easy to understand coding practices
• How to effectively test your applications
• Addressing security concerns

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.

So I was handed an ancient project which was up to me to fix / improve. About a week later I am about done but there is 1 thing I left...Login security. As it is now, it's just md5(password) that's saved in the database. Better then nothing, but far from good enough. My plan was to have a constant pepper in the class which handles the logins, then do something like crypt(pepper . $password) to store it, since that should generate a random salt and is slower then sha1 / md5 / etc. I feel this should be save enough, do any of you have any ideas on how to improve it (without non-standard extensions)?

There's lots of comments so far and a lot of them are following along the same lines - use a better method of encryption, something like crypt with Blowfish or something similar as well as some hashing (like HMAC).

They talk about common problems and solutions around their company's APIs (and others they've dealt with). They cover one of the most important part of any API's structure, security, and different methods of handling it (HMAC, Oauth, etc).

Others involved in the discussion are Jason Austin, Brandon West, Rob Richards and Luke Stokes. You can listen to this latest episode either through the in-page player, by downloading the mp3 or by subscribing to their feed.

There has been a lot of traction lately on the topic of the PSR "PHP Framework Interoperability Group". They are introducing two new proposed standards: PSR-1and PSR-2, both dealing with code formatting standards. [...] I have read both, and actually agree and think they are quite good. However, there's a deeper problem. Open Standards is something that the internet was built upon. From HTTP, E-Mail and HTML to ECMA Script (JavaScript), OAuth and JSON, open standards are everywhere. The problem with the entire PSR process is that it is not designed to produce open standards.

He describes an "open standard" and points to this RFC as an example of the open process they should result from. He talks about the importance of the process and how having more people reviewing and contributing their ideas could help find issues in the proposal. He issues a "call to the PSR team" to adopt this practice, allowing a more open flow to the ideas that are being proposed.

Note that I'm not asking to open the vote to anyone else. I'm not saying that standards should be approved by everyone in the community. There should still be a standards body that makes the final decision. But they should make that decision based on community input. They should actively look for and encourage open discussion prior to voting.

Cal's questions center around the Standards group and what kinds of discussions they have about the language and the progress the group has made so far (like PSR-0):

• What's the purpose of the group?
• Is the purpose of this group to take PHP from everyone's hands and enforce the "one true grace" on everyone?
• Is the group fulfilling its purpose or is it wandering off the path?

You can listen to this latest episode either via the in-page player, by downloading the mp3 or subscribing to their feed.