Re: Revisiting the "Named Arguments" RFC

From: Date: Sun, 12 Jan 2014 19:11:35 +0000
Subject: Re: Revisiting the "Named Arguments" RFC
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-71096@lists.php.net to get a copy of this message 
On 12/01/2014 10:07, Kevin Ingwersen wrote:


Am So. Jan. 12 2014 10:52:46 schrieb Lester Caine:


I simply have to ask. What do you think this will actually give you productivity wise?


Personaly, I think that it makes API’s a -lot- easier.



A great example of this is amqplib, as shown in this RabbitMQ tutorial: http://www.rabbitmq.com/tutorials/tutorial-one-php.html


Take this line:

   $channel->basic_consume('hello', '', false, true, false, false, $callback);

That's 7 arguments, 4 of which are booleans which control various options of the call.

If there was native support for named arguments, that could become (with absolutely no change to the library):

   $channel->basic_consume('queue' => 'hello', 'no_ack' => true, 'callback' => $callback);

Not only can I leave out the arguments I want defaulted, I don't have to check back to the library source to check which of those pesky booleans is which.

Now, you could re-design the lib to take some or all of those arguments as a single parameter of named arrays, but you then have to write a whole bunch of scaffolding to handle default values, non-existent options passed, mandatory options omitted, etc, etc.

This same kind of thing comes up a lot with constructors, which take enough arguments to populate all the private fields in the object. For "model"-type objects, passing an array can feel like you're creating one representation first (the array to pass to the constructor) and then "transforming" it into another (the object) when what you really wanted was to initialise the object directly.

I'd really love to have an elegant version of this included in the language.

Regards,
-- 
Rowan Collins
[IMSoP]

Thread (29 messages)

« previous php.internals (#71096) next »