What PHP6 Actually Needs

I haven't heard much news about the next version of PHP, but this my wish list.

Closures

So far all of the rumblings have been about closures not being "the PHP way", but I suspect the real reason is that it's just far to difficult because of the way the engine is built. In leiu of closures, any inline function declaration, even if it isn't scoped at all, and the ability to pass a function around as a variable would be insanely useful.


$my_function = function(){}
$my_function();
function named_function($callback){
    return $callback();
}
named_function(function(){});

Some of that is already legal. It's 2007, and create_function is so crazy stupid that I forget lambadas exist while I am coding PHP sometimes.

{ } is the new array()

It would be oh so nice to use the curly brackets as a hash/array/evil nested data type, just like everybody else. While we're on the subject, this would be even more dandy:


$my_array = {a: 'one', b: 'two'};

Parameter Collection in Functions

Keyword arguments are out, and that's fine. But could we pretty pretty please have this:


function my_function($one,$everything_else = array()){}
my_function('argument_one','these'=>'all','collect'=>'into','an'=>'array');

This is legal:


array('argument_one','these'=>'all','collect'=>'into','an'=>'array');

And I'm assuming internally that function arguments have got to be some sort of array, so why not?

Late Static Binding

I'm pretty sure I've read this is on the big list, but man on man do we need it.


Article::find(1);

really needs to be possible instead of


PicoraActiveRecord::find('Article',1);

Backwards Compatability

I'm not expecting it at all. But, why not bundle the 4.x and 5.x engines all into the same binary, and let us flag a script as being a certain version. Perhaps a nightmare. Just a thought.

Posted May 10th, 2007 at 10:15 pm by Ryan in Programming

Replies to this Post

PHP is hopeless. I've switched to ruby for everything I can =D

Posted May 11th, 2007 at 8:33am by chess64

I agree on closures, that would be nice to have in some cases, although we already have everything in place to emulate all of the shown. You can already do


$func = "my_func";
$func();

and


$func = create_function( '$arg1, $arg2', 'var_dump($arg1, $arg2);' );
$func();

Anyway, having real closures would be nice.

I'm strongly against the array syntax. PHP users are used to array() and I find it quite intuitive and readable. Andi already suggested to have [] for arrays in the way you want it with {}. I could live with [] since it looks similar to the current way arrays are accessed, but still, if my vote would count, I was against it.

Same goes for parameter collections. I cannot see any sense here. You can simple declare an array when calling the function. Does the array() really hurt you?

In contrast to that, I'm strongly for late static binding. So, it seems I like 50% of your ideas. ;)

Posted May 15th, 2007 at 11:42am by tobyS

Arguments are most assuredly passed in using an array. Grab that array using funcgetargs(). What you want to do may be too rigidly defined to be useful. You might try something similar to this. Works great.

     function tag()
        {
            $everything_else = func_get_args();
            $one = array_shift($everything_else);
        }

Now you have your first argument as $one and everything else dropped into an overflow array. Not having declared argument expectations roll over into an overflow array automatically is a nice safeguard for enforcing your API, and it's not hard to build a function/method with more flexible input, so I'd say we're pretty good where we are.

Posted May 15th, 2007 at 12:18pm by MonkeyT

MonkeyT, I already use this technique, but ruby really sold me on what I suggest as a default. Where we are at now isn't horrible, but it could be a little better.

Also wanted to add one more thing into the suggestion list, static method calls should be allowed in the class definition:

class Article extends ActiveRecord {
   self::hasMany('Comments');
}

right now this is what I use:

class Article extends ActiveRecord {}
ActiveRecord::hasMany(...);

Since the code would get executed as the class is declared (and so long as late static binding is fixed in PHP6), this doesn't seem terribly hard to implement. I know Zend wants their ActiveRecord implementation to be semantically pleasing...

Posted May 15th, 2007 at 12:45pm by ryan

ryan,

Understood. I've never worked with Ruby firsthand, but I do work with a lot of novice PHP developers, and I can imagine now what it would be like having to explain "OK, when you're declaring a function, this array() value here is not really a default value like the other ones you supply to the right of an equals sign: it's a control, standing in for any other values you supply when the function is called. It only works that way here, in a function's argument declaration. You can use this array() control, but you can only use it once (since there's no way for PHP to know where one array ends and another begins), and you have to use it at the end of the input declaration (for much the same reason)." and then dreading the inevitable "Why?". Under this one circumstance, "=array()" would do something entirely and utterly unique. Something very different from what it does elsewhere in PHP. That's not good. (Also, what happens when you actually DO want an empty array to be the default value of a supplied arg?) I'd rather have programmers understand the mechanics of the func _ get _ args() process. It solves the same problem, but it gives them more flexibility, even if it is a little longer. To me, it's an issue of understanding process versus memorizing an exception. I'm afraid I have to fall into the "That's not the PHP way" crowd, over this one. Simplicity doesn't always mean fewer keystrokes.

No offense. It's a subtle issue, and I enjoyed the article. (And for the very same reasons, I agree with you on the "{}" handling of array assignment, though I'd rather see it as "[]".)

Posted May 15th, 2007 at 2:25pm by

Thanks for the thought you put into explaining that. For newbies, I could see how that could be really confusing.

Posted May 15th, 2007 at 2:43pm by ryan

Js syntax for self initialization of arrays sucks big time in php: too similar to js to prevent people mixing their mental model when switching frequently between the two languages. I would favor allowing $arr = [$a, $b]; though
closures can be worked around really, and everybody has a hard time "getting" them the very first time - not really needed. Otoh anonymous functions that can be passed around would be a huge boon (create_function is plain dumb: ides f.e. cannot check syntax of the code inside the string argument)
parameter collection in functions: I personally find that quite confusing. And please never think about allowing mixed named and positional parameters
one thing I long for is scoping. I still have not accepted the fact that i cannot use $this as variable inside a plain function because the engine cannot tell (even at runtime!) if is being invoked as an object method or not

My 2c...

Posted May 16th, 2007 at 3:38am by gggeek

After some thought, I'll second what other folks are saying, to say that this is acceptable for arrays:


$a = ['one','two',3 => 'three'];

I still think parameter collection in the end would be fine, since it's optional.

Anonymous functions that can be defined like so are still a must (forget the scoping and closure bit though):

$my_func = function(){}

I suppose on an engine level, the problem then becomes if this is legal or not:


$object->some_method = function(){}

If we can just get anonymous functions in that syntax, I'd be fine saying that it can only really be a wrapper around create_function, and that functions won't be treated as a "real" first class data type.

Posted May 16th, 2007 at 2:27pm by ryan

There is one thing i would like to add, that is a true forking implementation, not using the pcntl* functions which are really only usefull on *nix.

Posted May 23rd, 2007 at 11:51pm by potsed

There is one thing i would like to add, that is a true forking implementation, not using the pcntl* functions which are really only usefull on *nix.


// do stuff...
fork(){
    // do child stuff here
    exit;
}
fork(){
    // do second child stuff here
}
// finish parent

Posted May 23rd, 2007 at 11:52pm by potsed

Posted July 24th, 2007 at 1:45pm by

Posted July 24th, 2007 at 1:51pm by

Posted July 24th, 2007 at 2:02pm by

need scope or namespace , delegate, anonymous and nesting function , Json .

Posted July 31st, 2007 at 11:38pm by sleets

LivePipe™