Re: Re: keyword arguments?

I think the disadvantages of named arguments outweigh the advantages. It adds to the languages complexity with a construct which will probably not be used that often, and which is likely to impact parameter binding performance. I do think that in these kind of cases, where you really do require the ability to continue to extend and extend a function prototype, a hash as the last argument isn't that bad. It would look something like this: func(1, 2 , array("protocol" => "http", "version" => "1.1", "compression" = "on")); Not too bad IMO. Just as another interesting point, if you'd use ->set()'s like Jevon describes you could also reach the following kind of code thanks to PHP 5. $f->setA($a)->setB($b)->setC($c); Of course this would require all set?() methods to return $this and it's questionable if this is nice style (I probably prefer the few lines over one such line) but just some food for thought :) Andi At 09:41 PM 6/24/2004 +1200, Jevon Wright wrote:

Wouldn't a good (not necessarily better) idea in your case be to use an object? Instead of

    function foo(named $a, named $b, named $c, named $d, ..., named $z)
    echo foo(a := $a, c := $c, e := $e, ...);

you'd have

    class Foo { ... }
    $f = new Foo();
    $f->setA($a);
    $f->setC($c);
    $f->setE($e);
    ...
    echo $f->doit();

This is clearer; all arguments are optional (unless you want to put required arguments in a constructor); and it basically does the same thing. And yes, it's about as much work as having a hash. Visual Basic supports named arguments (I used its style above). I've used it once in a function, but it had like 10 arguments - and it was a nightmare to try and code. I don't think the solution to extending functionality is to just add more arguments! Then again, I am still trying to instruct myself to the OO paradigm. What happens if you want to remove an argument from a function with named arguments? Either you'll have to remove it and search through all code and amend the calls (tiresome, error-prone), or you'd label the parameter "unused"/"deprecated". What happens if your function kept on changing? Before long you'll have 100 arguments with only 10 of them used at any one point... Just some thoughts... Jevon ----- Original Message ----- From: "Richard Mann" <richard.mann@gg.com> To: "Daniel Crookston" <daniel@hyperion-data.net>; "Bert Slagter" <bert@procurios.nl> Cc: <internals@lists.php.net> Sent: Thursday, June 24, 2004 8:53 PM Subject: RE: [PHP-DEV] Re: keyword arguments?

pretty soon you have function calls that look like this: xyz('a', 2, $foo, '', '', '', '', '', '', $bar);

I agree with this. I am working on a project where by the flexibility required of the object being written has spawned a massive collection of parameters. Many of these parameters are only required in certain situations and it is indeed the case that when I need to add one additional parameter to accommodate some new capability, I suddenly find myself with the task of either putting all the empty parameters in before it every time it is used or rewriting all instances of the function to place it towards the beginning. I can except that this can be avoided in many cases with better forward-planning, but it is defiantly desirable sometimes to simply have these flexible constructs available.

all that can be offset by write a complementary set of wrapper functions like: function xyzSuperSpecialFooBar($a, $b, $foo, $bar) { /* using the 7th optional arg - first 3 args required (or whatever)

*/

return xyz($a, $b, $foo, '', '', '', '', '', '', $bar); }

Not always ideal though. Having about 6 different aliases for essentially one function can get confusing for the developer to remember. My example is a HTML Form generator, whereby the actually generation of the form elements is alike enough to be handled by one algorithm, but requires some set-up, which includes various layout settings. I could do this with a different alias for each element, but this is more difficult to automate then simply passing a 'type' variable which can easily be programmed. Having said my peace in favour of named keywords (which I do think would be extremely handy), I must say that I am not convinced by any of the syntax put forward for using them yet. :-( Maybe something like: function a($a, $b=true, $c=>false) { ... } $c would be your named parameter. Sorry for dragging up old stuff. ;-) Subject: Re: [PHP-DEV] Re: keyword arguments? The major benefit of keyword arguments doesn't occur when you're writing functions, it occurs when you're re-writing them. I can't count the number of times where I've thought "My xyz function already does something almost exactly like what I need... if I just passed it an extra parameter, I could rewrite xyz to do what I need and save a lot of time." So I add another parameter, making it optional. This is fine, all the calls to xyz that are lacking the final parameter still work (since it's optional.) But do this once or twice, and pretty soon you have function calls that look like this: xyz('a', 2, $foo, '', '', '', '', '', '', $bar); That's ugly and unnecessary, and leaves lots of room for bugs when you're writing functions that use the nth optional parameter in your function (since you have to count the number of blank spaces you need to leave.) Additionally, what happens when all of your original, three-argument (a, 2, $foo) calls to xyz need to start passing an additional argument because of a change you couldn't predict when you first wrote your function? Keyword arguments solve these problems. They're always optional - not just optional in that you can stick a '' or NULL in the spot where you would put a value in the function call. They're optional in that you can leave them out entirely. Because they're named, they can also be passed in any order. And, finally, you can add new keyword arguments at any time, and none of your current function calls will break. If there's a way to do this in PHP (short of having the last argument be a hash) that I've missed, please let me know about it. Daniel Cr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php