In a new post to the Exakat blog they try to answer the question "how many parameters is too many" when it comes to the structure of the methods and functions in your application.

Now, that is a classic question, that is often a minefield for anyone writing an increasing long list of argument in a method, or simply trying to set up auditing tools.

Obviously, the answer is not immediate. Parameters may be needed, but on the other hands, currying functions allows to reduce the amount of parameter to one for every function. In between, probably exists a reasonable level that is a golden rule, and also very elusive. So, we decided to check the current practice in PHP code.

They started the research with some of PHP's own native functions that took in specific arguments, ignoring those that took an arbitrary number. Next they made a survey of 1900 open source projects to determine the common practice for parameters by function. The results showed that methods without at least one parameter were "less useful" and that a seemingly reasonable amount of parameters is 5. The post finishes with a spotlight of two they found during their research that had the most parameters: a generated class for database interaction and a dependency injection class.

In a new post to her site Lorna Mitchell encourages you to upgrade to better passwords by using either the built-in password hashing (since PHP 5.5) or by using the userland implementation (that works for >=PHP 5.3.7).

The password features in PHP aren't exactly new, but I see lots of applications from "before" which aren't being migrated to better practices. I have some strategies for doing these migrations so I thought I'd share my main approach, plus a similar-but-different one I saw in the wild (OK it was in CakePHP, so not too wild!).

She offers a few steps to follow to upgrade your application to use the bcrypt solution instead of your current format:

• Update Login Code (change SQL to just fetch the password, not evaluate it)
• Hash existing passwords
• Update registration code (for new passwords to use the new method)
• Migrate users with old passwords hashes once they've verified their current login

She also mentions alternatives to these approaches including forcing the user to change their password on login.

The MongoDB blog has a new post asking for feedback on what the user community thinks of their approach to supporting MongoDB functionality in PHP 5.x, HHVM and even out to PHP7.

Since the PHP driver first appeared on the scene, MongoDB has gone through many changes. [...] Beyond MongoDB's features, our ecosystem has also changed. [...] During the spring of 2014, we worked with a team of students from Facebook's Open Academy program to prototype an HHVM driver modeled after the 1.x API.

[...] Although the final result was not feature complete, the project was a valuable learning experience. The C driver proved quite up to the task, and HNI, which allows an HHVM extension to be written with a combination of PHP and C++, highlighted critical areas of the driver for which we'd want to use C. This all leads up to the question of how best to support PHP 5.x, HHVM, and PHP 7.0 with our next-generation driver.

They've shared the overview of the new driver structure including three layers: the system level functionality, the extensions themselves and a MongoDB userland library. They walk through the thinking on each of the pieces of the puzzle and how they all couple together to make for a more robust, flexible system that's also easy to use.

Evert Pot has shared some of his thoughts about why he has a problem with password_hash (and friends). His thoughts are initially about this particular feature but they're actually wider than that.

The initial introduction and rfc for these functions made me uneasy, and I felt like a lone voice against many in that I thought something bad was happening. I felt that they should not be added to the PHP engine. I think that we should not extend the PHP engine, when it's possible to write the same API in userland, or there are significant benefits to do it in PHP, such as performance. Since the heavy lifting of the password functions is done by underlying libraries that are already exposed to userland-PHP, it didn't make sense to me to expose it as well in the core.

He includes a list of things he sees as drawbacks for new C-based functionality in PHP including the fact that it extends the "PHP specification" and forces other projects to implement it (like HHVM). He does include a few positives, though, such as the increased visibility and legitimacy, but still thinks they don't outweigh the negatives.

For those that may not be able to update to PHP 5.5 anytime soon but still want some of the cool features that come with it, there's one more option for adding that to your current PHP install. Ben Ramsey has released a userland-version of array_column, the function that returns the values from one column for all values in an array.

Earlier this year, I wrote about how my patch for array_column() was merged into the development branch for PHP 5.5 in preparation for the beta release. I received a lot of great feedback and many kind words. Then, on June 20, the PHP team announced the general availability version of 5.5.0. With that, array_column() was released to the world for general use.

Many still use earlier versions of PHP, though. While the functionality of array_column() is simple enough to implement on your own in userland code, I’ve released a small library that implements it in userland code exactly as it’s implemented in the core, complete with the same PHP error messages and warnings.

The library has no dependencies and can be dropped into an existing application easily - just grab the source and include the needed file when you want to use the function (or it can be installed via Composer too).

In the theme of other recent posts mentioning the scalar type hinting that has been included in the main line of code that is headed towards the next PHP release, Sebastian Bergmann has a new post about their inclusion in PHP 5.3.99 (yes, that's PHP 5.4) and the new syntax it introduces.

In a nutshell, this means that PHP 5.3.99 introduces new syntax -- scalar type hints -- but no new semantics. The latter can either be implemented as an extension written in C/C++, in userland PHP code, or in a tool that statically analyzes the code.

He includes an example fro userland with a "php_check_parameters" function that looks at the arguments of the current method and uses Reflection to check against the type hints for the correct value type.

Johannes Schluter has posted about another update to be included in PHP 5.3 - an improved getopt function:

So PHP 5.3 has lots of new stuff offer, so let's take a look at one change: Added long-option feature to getopt() and made getopt() available also on win32 systems by adding a common getopt implementation into core. (David Soria Parra, Jani)

This gives Windows users a function they haven't had before in both web-based applications and on the command line. You can get more information about the use of the function from its page in the manual.

In this new post Jeremy Johnstone looks at creating a class to add that's missing from the basic datatype set of the language - enums.

I stumbled across a blog post on how to implement Enums in PHP via userland code written by Jonathan Hohle. I liked the concept he had, but the implementation was a bit unappealing because it used eval() among other more minor issues. You shouldn't need to generate Enums at runtime, so I took that as a challenge to find a way to do it at compile time, thus making the code much more efficient.

His enums would support type hinting and would, ideally, be iterable. He gives the code he's worked up - a base class, another than extends it to make a basic enum structure and some handy changes to support comparisons. A few more changes (and a few other extended classes later) he has some pretty well functioning enums that can even bee iterated through.

On the PHP Addiction blog today, there's a new post where Doug Hill asks a question of his fellow developers - are there advantages to having a standard container library for PHP?

Most compiled languages that I have used have some kind of container implementation, Lists, Maps, Trees, Stacks and all their many variations. PHP has arrays and the SPL.

The only problem he's noted so far is that containers made in userland would be slower than ones created natively. A comment from Antony Dovgal points out a project similar to what he's looking for that's already in the works.

On the PHP Addiction blog today, there's a new post where Doug Hill asks a question of his fellow developers - are there advantages to having a standard container library for PHP?

Most compiled languages that I have used have some kind of container implementation, Lists, Maps, Trees, Stacks and all their many variations. PHP has arrays and the SPL.

The only problem he's noted so far is that containers made in userland would be slower than ones created natively. A comment from Antony Dovgal points out a project similar to what he's looking for that's already in the works.