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" <[EMAIL PROTECTED]> To: "Daniel Crookston" <[EMAIL PROTECTED]>; "Bert Slagter" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> 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
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
