Re: Re: PHP 6.0 Wishlist

From: Date: Sat, 13 Aug 2005 23:43:38 +0000
Subject: Re: Re: PHP 6.0 Wishlist
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-18007@lists.php.net to get a copy of this message
George Schlossnagle wrote:
Huh? Perl doesn't have true support for this anyway, just a simpler syntax for hashrefs. If you want Perlish named params this is 100% identical to doing foo(array('id' => 42, 'name' => 'foo'));
If you are using this a lot then syntactic sugar does make a difference IMHO. That's why we decided to use a patch to allow foo('id' => 42, 'name' => "foo"); I agree that a fancier way would be to have something like function foo($id = 42) { ... } ... foo(id: 64738, name: "foo"); and then access them through $_PARAM['id'] (or $id because the function definition declares $id) and $PARAM['name'] respectively. What I don't like about Python at all is that AFAIK you can't call a method with parameters not declared in the function definition. That's a very handy feature for things like DB actions or HTML generation. Missing from the fancier version: Parameter names which aren't valid identifiers and preparing an array with values before calling a function. The first is a more hypothetical limitation as fields/attributes are normally not containing non-identifier characters but the second is a bit more practical: $record->insert('id' => 42, 'name' => "foo"); works just as well as $tags = array('id' => 42, 'name' => "foo"); ... # Add more key/values to $tags $record->insert($tags); without requiring insert() to distinguish between the two. If someone can come up with an elegant way to populate $_PARAM on a function call then both these limitations would be gone. That's it about named parameters from my side for now, - Chris

« previous php.internals (#18007) next »