Skip links

Currently on PHP's internals...

June 10, 2011 at 12:12 PM - by Freek Lijten - 4 comments

Tags: ,

The internals list is the place to be to hear about the current state of PHP. It is one of PHP's many mailing lists, but this is the one where (core) developers discuss new features, current bugs and wild ideas. If you want to keep up with things it is a good idea to sign up, it is not an extremely high volume list and if you ignore the noise it is quite informative. In this article I would like to share examples of stuff typically discussed on the list.

The first, and perhaps most major, item I want to discuss is an RFC for a release process. PHP isn't exactly known for its smooth release process. PHP 5.3 took some time (understament of the century), and PHP 5.4 isn't exactly out yet either. While it was first mentioned as early as 2008! On top of that several tries to get a alpha out for 5.4 have stranded in discussion over what should and what shouldn't be included. Check out this thread for instance.

So releasing isn't going smooth, thats exactly why a group of developers took the time and effort to write up their ideas for a release process. I personally think it would be great if some sort of process would be established. Right now attempts at getting an alpha out all smother in discussion over one or two single features. It is no problem that discussion on said features takes place, but it is a shame that it holds back other great features which are since long ready and implemented.

Some features

While the RFC hopefully leads to something great it is not a feature request and I spoke of those too. So lets have look at some of them. I chose two features which seem to have met general consensus on their usefulness so chances are, you will once see them in action in PHP 5.4, whenever it might be released :)

Traits

The first example I'd like to share is a concept called traits. By now, PHP has a decent object oriented model but it lacks a feature. PHP only knows single inheritance making it impossible to create a class inheriting from more than one class.

I'll give an example where multiple inheritance was necessary for us. At Procurios we have a partial output cache called the fragment cache. This concept consists of a class that needs to be extended. There are however situations where a class that needs to be cached already extends from another class. For this situation an interface was created, defining several methods that needed to be implemented. The list of methods however grew and grew, and the interface itself was implemented at several places, in other words we were duplicating code.

We're now working around this problem by instantiating the fragment cache object inside the classes which couldn't extend but needed the cache functionality, but it is far from ideal. Below there is an example of how we could have used traits to solve this problem far more elegantly.

trait Fragment
{
    public function setFragmentInfo($fragmentInfo) { ... }
    public function setFragmentParameters($fragmentParameters) { ... }
    //etc...
}

//kiwi is a class which provides functionality to what are essentially smart dataobjects
class Article extends Kiwi
{
    use Fragment;

    public function getContent() { ... }
    public function moveTo($nodeId) { ... }
    //etc...
}

$Article = new Article($articleId);
$Article->setFragmentInfo(array( ... ));

This method is very much preferable to our current situation. The keyword use and the name Fragment after it ensure that the Article class could use all public functions of the trait as if it were its own. With traits the functionality needs to be implemented only once, and every random other class in our framework can use it without modifying the classes they extend from.

Array dereferencing

Another feature which is commited to TRUNK is array dereferencing. This functionality is best demonstrated with another code example (taken from the RFC):

function fruit() 
{
  return array('a' => 'apple', 'b' => 'banana');
}

//what you would normally do
$fruits = fruit();
echo $fruit['a'];

//what array dereferencing enables
echo fruit()['a'];

Simple right? In short array dereferencing enables you to treat the function result for what it is, an array :)

A newer feature

The two former examples are both features which are already committed to TRUNK, I would also like to give a recent example. This example concerns a concept introduced on June the 5th, introducing an array as callable. This is a vague description, I hope to clarify it a bit below. First an example with a string:

function bar($baz) 
{
    echo $baz;
}

$f = 'bar';
$f('baz'); //echo's the string "baz"

The code above is already possible in PHP, the callable array introduces the possibilities below

class Foo 
{
    public function bar($baz) 
    {
        echo $baz;
    }
}

$f = array('Foo','bar');
$f('baz'); //echo's the string "baz"

//also works
$Foo = new Foo();
$f = array($Foo, 'bar')
$f('baz');

Goodbye call_user_func?

A hot debate

Of course not all features meet a consensus. There is a reason the release process would come in handy remember? One of those features currently responsible for delaying a new attempt at 5.4 because of its hotly debated nature is the short array syntax. It is an RFC proposing a javascript alike method for creating arrays:

$a = [0, 1, 1, 2, 3, 5, 8];

$a = [0 => '0', 1 => '1', 1 => '1', 2 => '2', 3 => '3', 5 => '5', 8 => '8'];

$a = [0 : '0', 1 : '1', 1 : '1', 2 : '2',3 : '3', 5 : '5', 8: '8'];

What is the debate about you ask? Two things, firstly if it is useful at all, secondly about the way it should be implemented: should the notation use colons or => as seperator. Something which looks as minor as this can result in hundreds of messages and can postpone an entire release. Once again, the discussion is great, no feature should make the language without proper discussion and thinking (especially this one), but is is such a shame other features are stalled by this as well. I've said it once, I'll say it again: release process :)

Final message

So we've seen some features under discussion or even implemented in the current TRUNK. I hope this article gives an idea of the topics discussed on internals and that it inspires you to follow the list (more) actively. What is discussed there is the future of our language, if you want to see it enfold, the list is the place to be.

[edit]

I wrote this post just before the heavy discussion on the atmosphere on the list broke loose. See Stefan's blog for some more info. I do agree with most of the stuff he says, but I also remain confident that, all emotion and bad behaviour stripped out, the list remains an interesting place to check on the latest developements.

[edit2]

There actually is a very first tag for an alpha of php 5.4!

Share this post!

Comments

  1. Dave SmithDave Smith Wrote on June 16, 2011 at 6:17:45 PM

    Thanks for the insight. Can't say I'm in favour of traits myself: they're just code duplication in denial. Plus I tend to think that if multiple inheritance is the answer, you might be asking the wrong question, and inheritance (already well overused) probably isn't the pattern you're looking for.

    It seems a particularly, uh, original way to implement caching, for example, but as I haven't seen the system in question I'll reserve judgment!

  2. PetahPetah Wrote on June 17, 2011 at 12:50:00 AM

    They need to just pick a short array syntax and stick it it. I mean, who really cares, we all want short arrays, and I would rather just have it even if the syntax was not my preferred (I'm sure we have all found syntax in PHP we dislike, but deal with anyway).

    Anyway, my personal preference is

    ['key' => 'value']

    To maintain consistency with existing syntax (it would also be a quick and easy search and replace to update existing code).

    @Dave Smith, I disagree. I can see many use cases where traits will be a great enhancement.

  3. haraldharald Wrote on June 17, 2011 at 11:25:53 AM

    mmm ... what about short object syntax? it seems, that they will not include it and this would -- imo -- be really crap. the current state is, that you have to explicitly cast to object:

    (object)array(...)

    i also can't find anything about $this support in closures (solution for accessing private / protected properities of an object from a closure). the last thing i heard was, that there is a solution in trunk, but will it get into 5.4?

  4. FreekFreek Wrote on June 20, 2011 at 9:16:02 AM

    @Dave Smith

    Thanks for your reaction. I wanted to clarify the concept of what we call the "fragment cache" a bit more. It is more generally known as partial output cache, frontend output cache and other terms. Zend framework amongst others have solutions for this. To read a bit more on how we use this type of caching I refer to this article.

    @Petah

    To be honest I don't really see the need for the short syntax but I do agree on the syntax you like best as well. Consistency is a good thing :)

    @harald

    There is indeed a solution for $this support in trunk and according to this list it will make 5.4

Leave a comment!

Italic and bold

*This is italic*, and _so is this_.
**This is bold**, and __so is this__.

Links

This is a link to [Procurios](http://www.procurios.nl).

Lists

A bulleted list can be made with:
- Minus-signs,
+ Add-signs,
* Or an asterisk.

A numbered list can be made with:
1. List item number 1.
2. List item number 2.

Quote

The text below creates a quote:
> This is the first line.
> This is the second line.

Code

A text block with code can be created. Prefix a line with four spaces and a code-block will be made.