Falcon

Falcon (Photo credit: Stephen & Claire Farnsworth)

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. C is the arcane spell-book from which PHP Internals conjures up new PHP versions and other people summon PHP extensions. If you asked a PHP programmer to learn C, they’d probably put on a frozen smile while desperately searching for the nearest exit.

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. Your first thought right now is probably to sigh heavily at the thought of yet another damn programming language. Try not to. Zephir was designed for PHP programmers which means it looks like PHP, feels like PHP and allows you to use PHP’s typical functions, classes and constants. There are certainly important differences but it’s laughable to even suggest that these are insurmountable learning barriers.

Zephir is basically a bridge. It allows you to generate the C code used to compile PHP extensions from the much simpler Zephir code you write. Write some Zephir code, invoke the command line tool, and Zephir will generate and optimise the necessary C code, invoke the local C compiler to build the extension, and even install the extension for you. The rationale should be obvious: writing Phalcon’s next major version in Zephir will make it far easier for the PHP community to contribute without mucking around with C and without sacrificing Phalcon’s performance advantage over other frameworks. Like so many open source projects, Zephir was born out of need.

As to the difficulty of learning Zephir, here is a sample Zephir class:

namespace Test;

class Hello
{
    public function say()
    {
        echo "Hello World!";
    }
}

Yes, it looks exactly like PHP. Now, let’s tailor the above example (which compiles to a PHP extension just fine by the way!) to show some of Zephir’s differences:

namespace Test;

class Hello
{
    public static function say() -> void
    {
        var message = "Hello World!";
        echo message;
    }
}

The above demonstrates three obvious differences. Variables in Zephir do not require the dollar sign, but do need you to both declare them and define them as having either a variable type (the same as normal PHP variables) or a static type. Above, I declared message as having a variable type. Honestly, this is kind of silly and I should have just declared it with the static type, string, since the variable is obviously not going to switch type. I just didn’t want anyone’s neurons to get fried yet. To assist in detecting errors, I also hinted to the compiler that the method should return nothing, i.e. void. This hinting is optional but allows for some error checking when compiling. Oh, another difference is that the file does not start with “<?php”.

Now, before we get overly excited, you should know that Zephir is a work in progress. At the moment, it’s very usable but it is not a 1 to 1 reflection of PHP’s features. For example, if you try to assign a predefined PHP constant when defining a property in a class, you’ll get a syntax error. There is therefore a line where your understanding of PHP won’t translate across to Zephir completely. These small unexpected issues are the ones most likely to frustrate you but they often have simple workarounds (e.g. you could assign the constant in the constructor). The list of Zephir issues on Github also show that fixes are generally rapid. There are larger features missing compared to PHP, and more than a few significant differences, but those are easier to accept, and far less frustrating, given Zephir is still in development.

No discussion of Zephir can be complete without addressing the elephant in the room: HHVM (the Hip Hop Virtual Machine). In theory, with all edge cases resolved in its ongoing race for parity with PHP, you could write an application in PHP and just chuck it at HHVM to gain significant performance benefits. If you can do that, then why bother with Zephir? Isn’t it simply a superfluous language? Here’s the thing, the chances of all PHP programmers using HHVM in production is pretty much zero. I’m open to being proved wrong over the next 5 decades I hope to live through but this isn’t a programming language’s first encounter with a generally better performing implementation though it is (for many) PHP programmers their first time learning where to assign responsibility when PHP parity issues arise. One thing I can’t help but mention: if my code doesn’t work on HHVM, do not assume that it’s my job to fix it when it works perfectly on PHP 5.5′s Zend Engine!

Zephir therefore still offers a boon to programmers who want the possibility of speeding up particularly slow sections of code without making assumptions about the final production environment and without inflicting C on PHP programmers. In other words, if you’re an open source project, watch your back. A Zephir project is going to be both better performing and almost as accessible to PHP programmer contributions as a native PHP alternative. That’s a powerful concept.

Phalcon 2.0 Alpha 1, written in Zephir, was released two days ago.

It lives!

Over the course of my next few blog posts, I’m going to play with Zephir. Expect me to curse it, praise it, break it, and probably wind up in a padded cell of my own. I might even end up with a PHP extension.

Enhanced by Zemanta

Related posts:

  1. Who fancies a community effort to write a PHP book?
  2. Example Zend Framework Blog Application Tutorial – Part 6: Introduction to Zend_Form and Authentication with Zend_Auth
  3. Is PHP A Worthy Template Language? Well, of course it is…
  4. Programming is a language – use it correctly
  5. Sourceforge recognise the Irish Language