On thePHP.cc site today they have a quick post that looks ahead at the future of the PHP language towards PHP version 8 and one planned feature - the deprecation of some multi-byte character handling.

Since the attempt to create a Unicode-based PHP implementation has failed, PHP 7 – just like PHP 5 – does not handle Unicode strings natively. The commonly used UTF-8 encoding, for example, is a multibyte encoding, as opposed to ASCII, where each character is represented by one single byte.

[...] UTF-8 is a variable-length encoding and each character (code point, to be exact) is represented by one to four bytes. For ASCII characters, everything works smoothly, because UTF-8 is a superset of ASCII. The problems start with non-ASCII characters.

The post covers some of the common issues with multi-byte Unicode characters in PHP and the role that the iconv and mbstring functions play in their handling. It shows how the mbstring handling allows developers to "cheat a little" and where, when PHP 8 comes around, the main issue will lie: the deprecation of thembstring.func_overload setting in the php.ini.

Freek Van der Herten has a post to his site showing how PHP functions can (sort of) be overloaded with the help of a trait from Adam Wathan.

PHP does not support method overloading. In case you’ve never heard of method overloading, it means that the language can pick a method based on which parameters you’re using to call it. This is possible in many other programming languages like Java, C++.

However, with some clever coding, Adam Wathan made a trait, aptly called Overloadable, that makes method overloading possible. It works by just accepting any parameters using the splat operator and then determining which of the given functions must be called according to the given parameters.

He shows how to use the trait in a simple example, defining a single "bar" function and using the "Overloadable" trait to handle the switching between the methods based on the input variables. You can find more information about the trait and the source for it in this gist over on GitHub.

Derick Rethans has a new post to his site starting a series of posts about the new features of Xdebug 2.3. In this new post he talks about an improvement that's been made to the output provided by var_dump with more information than before.

One of the new features relates to one of the first things that I added in the original Xdebug: making the var_dump() output "pretty". Xdebug replaces PHP's standard var_dump() function with its own version, as long as the xdebug.overload_var_dump setting is not set to 0. [...] Xdebug 2.3 enhances the overloading of var_dump() with the inclusion of the file name and line number where var_dump() is called at. This has been a long standing feature request.

He provides a few sample screenshots comparing the old and new output formats and mentions another handy setting, xdebug.file_link_format, that makes the resulting filename a link in a browser and lets you customize the format.

On the PHPClasses.org blog today there's a new post looking at the security vulnerability that effected not only PHP but lots of other languages making them susceptible to attack from the outside.

In PHP and several other languages used to implement Web applications, arrays are used to store the values of request variables such as $_GET, $_POST, $COOKIE, etc.. IF you receive a request with a large number of request values, until recent versions PHP may run into trouble.

He goes on to explain why there's an issue with the array overloading and what PHP has done in recent releases to help correct the issue - the max_input_vars setting in the php.ini. He also points out that this is not a new issue - it was originally identified back in 2003 (with a video of the original presentation). He points out that the most recent releases of the PHP language have this fix in them and, if at all possible, you should upgrade to protect your applications.

In a new post to his blog Nikita Popov talks about a little trick with inserting values into arrays that can make it take a lot longer than it should (because of how PHP stores its array values in hashtables).

PHP internally uses hashtables to store arrays. The above creates a hashtable with 100% collisions (i.e. all keys will have the same hash). [...] Because every hash function has collisions this C array doesn't actually store the value we want, but a linked list of possible values. [...] Normally there will be only a small number of collisions, so in most cases the linked list will only have one value. But the [included script] creates a hash where all elements collide.

He explains why it works, noting that it's relatively simple to do in PHP because of how it applies a table mask. The slowness comes in when PHP is forced to go through the entire list when it tries to insert. Because of this issue, there's the potential for a Denial of Service attack that could potentially take a server down. There's a fix already in place for the problem, though, so keep an eye out for the next release (that will include a max_input_vars setting to prevent it).

In this recent post to his blog Johannes Schluter talks about a method he's suggested for testing objects in unit tests - overriding the "new" operator to replace specific classes with mocks.

Two years ago at some conference I had a conversation with Sebastian about the need for a way to overload the new operator in PHP so, probably, bad designed code can be tested more easily by replacing specific classes with mocks. [...] Sebastian then pushed the code as part of a new test_helpers extension with some documentation to github and I fixed some bugs in it. The aim of the extension is to collect functionality which might be beneficial for phpUnit and other test scenarios but which should never reach a production environment.

He includes some sample code to show it in action - defining the mock class, using the set_new_overload function to define it as what should be called when the "new" operator is used and a dump of the result.

Martynas Jusevicius has a new post looking at method overloading in PHP5 - a workaround to make it possible at least.

Method overloading (a feature of object-oriented programing which allows having several class methods with the same name but different signatures) is not implemented in PHP, which is a drawback compared to Java. However, PHP 5 provides a way to imitate overloading by catching calls to "inaccessible methods" with magic method __call.

In his example he uses __call to route the request to the correct version of the constructor (__construct0 or __construct1) based on the number of arguments passed in

Eran Gelperin gives an overview of the current state of overloading abilities PHP has in a new blog post today:

Operator overloading is a programming language features that allows operators to act differently depending on the type of data they are operating on. Since OOP lets us create custom types (classes), there are plenty of opportunities to do useful and interesting code manipulations using operator overloading.

He talks about magic functions, the additions that the SPL made, the PECL addition operator and how much its currently being discussed on the PHP internals list.

Thanks to it being posted on reddit, the traffic to a certain post on Michael Kimsal's blog gave him a crash (literally?) course in high load management on a WordPress blog.

The blog post was voted up on reddit, and the server got slammed. So slammed, in fact, that it was unusable for a few hours while I investigated the problem. I didn't know the post was on reddit, but I knew I was getting some traffic.

He spent some time trying to get the Apache server to finally die off and give him back his machine, at least enough to get a feel for what was going on. Part of his problem was not having APC installed like he thought and the other part - WordPress. While friendly on the outside, it's apparently somewhat lacking on the inside.

In a new post to his blog, Matthew Weir O'Phinney talks about a method for overloading arrays in a script written for the PHP 5.2 series.

Several weeks back, a bug was reported against Zend_View that had me initially stumped. [...] I'd read about this some months back on the php internals list, but at the time hadn't understood the consequences.

Basically, __get() no longer returns a reference and returns values in read mode, which makes modifying arrays using overloading impossible using traditional methods.

Unfortunately, this was exactly the functionality that was needed, so Matthew set out to find a way to do just that. His initial method, extending the ArrayObject, worked but still gave errors. On Mike Naberezny's recommendation, though, this too was resolved with a simple call to the __set method instead.