The SitePoint PHP blog has a new tutorial posted (a repost from this article used with permission) about implementing a new operator in the PHP core language: a "range" operator. This operator allows the definition of a range of values (integer/float) as an internal PHP representation.

In the post below, Thomas Punt implements the range operator in PHP. If you’ve ever been interested in PHP internals and adding features to your favorite programming language, now’s the time to learn! This article will demonstrate how to implement a new operator in PHP. The following steps will be taken to do this: updating the lexer, updating the parser, updating the compilation stage and updating the Zend VM. This article therefore seeks to provide a brief overview of a number of PHP’s internal aspects.

He starts with a look at the range operator and how the intended functionality would work (including when the errors would be thrown). He then goes through the steps listed above and makes additions to the source, complete with the C code to make each change. The article is not only a good look at how to add a custom operator but also gives a good overview of the internals of PHP and how things fit together.

Julien Pauli has a recent post to his site that "zooms in" on objects and classes with a look behind the scenes at how they're handled in the PHP source (at the C level) with plenty of code examples and explanations as to how they work.

Everybody uses objects nowadays. Something that was not that easy to bet on when PHP5 got released 10 years ago (2005). I still remember this day, I wasn't involved in internals code yet, so I didn't know much things about how all this big machine could work. But I had to note at this time, when using this new release of the language, that jumps had been made compared to old PHP4. The major point advanced for PHP5 adoption was : "it has a new very powerful object model". That wasn't lies. [...] Here, I will show you as usual how all this stuff works internally. The goal is always the same : you understand and master what happens in the low level, to make a better usage of the language everyday.

The article does a great (if lengthy) job of covering everything that happens with PHP's objects and class system, including stats about memory consumption. He includes both the PHP code and the C code to illustrate what's happening with classes, interfaces, traits and object methods/attributes (including object references). He also talks about what "$this" is and how class destructors are handled.

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.

In the new post to his blog Pádraic Brady starts a series looking at building PHP extensions "the easy way" using the Zehpir language, a derivative of PHP.

When I first heard about the Phalcon framework for PHP, my immediate reaction was to doubt the sanity of its developers. Part of that reaction is something most of us would share: we are not C programmers and that strange alien language sometimes terrifies us. [...] Now, with no padded cell yet in evidence, the Phalcon people decided to do something truly insane. They created an intermediate programming language called Zephir, easily learned by any PHP programmer, that makes creating and maintaining the PHP extensions you do create ridiculously easy.

Zephir is a "bridge" making it easier to create the C code required to build a PHP extension but with the more familiar format we're used to as PHP developers. He includes a simple "Hello World" example and talks about some of the differences between it and PHP. He also briefly talks about some of the things Zephir can't do right now and how it relates to the HipHop Virtual Machine (HHVM) and what advantages it might have over it.

In a new post Sherif Ramadan takes an in-depth look at PHP arrays and what happens behind the scenes when they're put to use.

PHP is one unique language where the array data type has been highly generalized to suit a very broad set of use cases. [...] I’m going to share with you some of the underlying details of how the PHP array data type works, why it works the way that it does, how it’s different from other languages, and what behaviors the PHP array has that you may not be fully aware of.

He starts with a section looking at what arrays actually are in PHP (and how they compare to the lower level C arrays). He gives a C-based array example and shows how it's stored in memory. He points out how PHP arrays are different from other languages and shows the C code that works behind the scenes to create the array (actually a hashtable). He gets into a detailed explanation of the iteration of arrays including some basic benchmarks of some of the various methods and gets more in-depth with foreach (including subarrays and arrays containing references).

Nikita Popov has a new post to his site looking at how you can add your own syntactic features directly to PHP (requires knowledge of the C language).

Several people have recently asked me where you should start if you want to add some new (syntactic) feature to PHP. As I’m not aware of any existing tutorials on that matter, I’ll try to illustrate the whole process in the following. At the same time this is a general introduction to the workings of the Zend Engine. So upfront: I apologize for this overly long post.

He covers the usual "life" of a PHP script, how tokenization is handled and what happens when the script is parsed, compiled and executed. Code snippets are included to show you the points to add in your own syntax item - in their case, adding an "in" operator to see if a value is in an array (a one word version of this).

In a new post to his blog Derick Rethans mirrors the call made by Rasmus Lerdorf at this year's PHP UK Conference - get involved (and help test PHP)!

At the PHP UK Conference Rasmus mentioned that he wants more people contributing to PHP. There are plenty of ways how you can do that.

Derick points out two more immediate ways you can help, one not even requiring any C knowledge:

• Help test the Release Candidates (like the current PHP 5.4.0 RC8) with a call to "make test" just after your compile.
• The recently added "random PHP bug" functionality that's been added to the bugs.php.net site

Marcelo Gornstein has posted a new article showing how to use SWIG and libpcap to sniff packets from the network directly from his PHP application.

I've been wanting to try SWIG for a long time, but never got the chance, for one thing or the other. So this weekend I've finally decided to give it a try by trying to create a php extension that access a small C++ wrapper for libpcap, so I can sniff packets directly from PHP. Just for fun (and actually because I couldn't find any active pecl extension to use libpcap, so it might as well be something useful). I've named it "SimplePcap".

He includes both the sample code showing the extension's usage and an example of the output from his local "eth0" device. His PHP script uses SWIG to interface with the pcap_t/Packet class structure via this interface file and typemap.

SWIG is really great. I just did some C++ code and then worried about how to integrate it to PHP. Althought it seems that you really need lots of experience with it to actually do more advanced things in the right way. [...] So I guess that sometimes it's more productive to just make the PHP extension than using SWIG. But if you want your code to be run in many languages, this is definitely an excellent library to try!

On PHPMaster.com today there's a new post from Matthew Turland talking about PHP's quest for performance and some of the recent advancements that have made better performing applications even more possible.

While it’s sufficient for many users, as PHP sees increased use by large sites like Wikipedia and Facebook, the ability to serve more requests on fewer servers becomes increasingly important. Some efforts have been made in this area in the last few years, both within and outside the PHP internals team. However, understanding exactly what’s going on requires a bit of background both in history and concepts.

He goes through some of the origins of the PHP language (from the early days with Rasmus Lerdorf) to the fact that the PHP language itself is interpreted - complete with some of the overhead that comes with that. He also mentions various projects that have tried to compile PHP back down to C to increase performance like Roadsend, HipHop and, most recently, the HipHop virtual machine from Facebook.

In this recent blog post nikic takes an in-depth look at how large PHP arrays really are - how memory is used in the creation and management of these handy PHP variable types.

In this post I want to investigate the memory usage of PHP arrays (and values in general) using the following script as an example, which creates 100000 unique integer array elements and measures the resulting memory usage. [...] How much would you expect it to be? [...] Now try and run the above code. You can do it online if you want. This gives me 14649024 bytes. Yes, you heard right, that’s 13.97 MB - eightteen times more than we estimated.

He goes into the details of PHP's memory management and breaks it down into the different totals (for 64 bit and 32 bit OSes) and details on each - zvalue_value, zvalue, cycles collector, Zend MM allocator and the buckets used to isolate one array (hash table/dictionary) from another.

What does this tell us? PHP ain't C. That's all this should tell us. You can’t expect that a super dynamic language like PHP has the same highly efficient memory usage that C has. You just can't.