# Named arguments revisited - Thread: https://externals.io/message/21488 - Original archive: https://news-web.php.net/php.internals/21488 - Started by Frank M. Kromann on 2006-01-12T15:54:54+00:00 - Messages: 18 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #21488 — Frank M. Kromann — 2006-01-12T15:54:54+00:00 URL: https://externals.io/message/21488#21488 > > If you have too many parameters that you want to start omitting parameters when calling a function, its probably time to refactor. > And if you have many parameters to functions you still need to look at the definition (or documentation) to figure out what parameters the function takes. It's not a big problem to look at the order at the same time. - Frank --- ## #21491 — Hartmut Holzgraefe — 2006-01-12T16:49:50+00:00 URL: https://externals.io/message/21488#21491 · In reply to: #21488 Frank M. Kromann wrote: > And if you have many parameters to functions you still need to look at the > definition (or documentation) to figure out what parameters the function > takes. It's not a big problem to look at the order at the same time. lets face the opposite direction for a second: all those string functions with different order of haystack and needle named parameters could help to reduce the criticism we get for this poor choice of parameter order in the past ... -- Hartmut Holzgraefe, Senior Support Engineer . MySQL AB, www.mysql.com --- ## #21493 — Andrei Zmievski — 2006-01-12T17:46:37+00:00 URL: https://externals.io/message/21488#21493 · In reply to: #21491 Hartmut, there are only 2 or 3 of those functions where the order differs. -Andrei > Frank M. Kromann wrote: > > […] > > lets face the opposite direction for a second: > > all those string functions with different order of haystack and needle > > named parameters could help to reduce the criticism we get for this > poor choice of parameter order in the past ... > > -- > Hartmut Holzgraefe, Senior Support > Engineer . > MySQL AB, www.mysql.com --- ## #21494 — Hartmut Holzgraefe — 2006-01-12T18:08:42+00:00 URL: https://externals.io/message/21488#21494 · In reply to: #21493 Andrei Zmievski wrote: > Hartmut, there are only 2 or 3 of those functions where the order differs. but it's the fact that it differs at all that counts ... -- Hartmut Holzgraefe, Senior Support Engineer . MySQL AB, www.mysql.com --- ## #21495 — Ron Korving — 2006-01-12T18:52:39+00:00 URL: https://externals.io/message/21488#21495 · In reply to: #21494 Another nice use case is querybuilders: $query = buildQuery(select: $columns, from: $tables, leftjoin: $leftjoins, limit: 10); It's nice to be able to stick to what matters, and omit everything that doesn't matter (ordinary joins, where, group by, having). With `func_get_args()` returning an associative array, one could also, for example, generate html tags (with parameters being attribute names with their values). Named parameters would add a lot of flavor, while being 100% backward compatible. - Ron "Hartmut Holzgraefe" wrote in message news:43C69B2A.8000802@php.net... > Andrei Zmievski wrote: > > […] differs. > > but it's the fact that it differs at all that counts ... > > -- > Hartmut Holzgraefe, Senior Support Engineer . > MySQL AB, www.mysql.com --- ## #21532 — Aidan Lister — 2006-01-15T07:17:28+00:00 URL: https://externals.io/message/21488#21532 · In reply to: #21495 Ron Korving wrote: > Another nice use case is querybuilders: > > $query = buildQuery(select: $columns, from: $tables, leftjoin: $leftjoins, > limit: 10); > We've seen a large number of cases where named parameters would be extremely useful. To each case, there has been a half baked attempt to dismiss the usefulness of the purported design. For example, > If you have too many parameters that you want to start omitting > parameters when calling a function, its probably time to refactor. Refactor? If you have a number of required options to get a result, refactoring isn't going to change that. Also, > And if you have many parameters to functions you still need to look at > the definition (or documentation) to figure out what parameters the > function takes. It's not a big problem to look at the order at the > same time. That's not the point, at all. It annoys me that good points are being dismissed with such ridiculous counter-arguments. No one is suggesting that people shouldn't look at the definition. Nor that people have problems remembering parameter order (I do, but again, not the point). In fact, named parameters allows people to quickly look at the definition to see what options are available. This is one reason named parameters are an improvement on associative array parsing. The problem is when an option needs to be changed which just happens to be at the very end of the function signature, function calls start looking like this: foo(null, null, null, null, null, null, true); Anyway, enough rebuttal. I think it's now incredibly obvious that the wider community would like to see named parameters in PHP 6. Are the PHP group prepared to accept and implement a named parameters patch? --- ## #21533 — Rasmus Lerdorf — 2006-01-15T07:51:29+00:00 URL: https://externals.io/message/21488#21533 · In reply to: #21532 Aidan Lister wrote: > Are the PHP group prepared to accept and implement a named parameters > patch? As far as I am concerned it would depend on the patch. If you can come up with a way to do it with requiring rewriting all 4000+ functions out there, go for it. -Rasmus --- ## #21535 — Zeev Suraski — 2006-01-15T09:20:28+00:00 URL: https://externals.io/message/21488#21535 · In reply to: #21533 At 09:51 15/01/2006, Rasmus Lerdorf wrote: >Aidan Lister wrote: > > […] > >As far as I am concerned it would depend on the patch. If you can >come up with a way to do it with requiring rewriting all 4000+ >functions out there, go for it. As Andi said, that's hardly the big issue (we could have provided it as a userland feature, not applicable to internal functions, or applicable to just a small subset of them). The big issue is whether or not we want that feature in the language, and the answer appears to be no. Zeev --- ## #21536 — Zeev Suraski — 2006-01-15T09:31:41+00:00 URL: https://externals.io/message/21488#21536 · In reply to: #21532 Aidan, People often mention the 20/80 rule, we're so far away from there that it's not even funny. It's more like the 1/99 rule, not to mention 0.0001 / 99.9999 rule. That means that even if we could come up with a way to improve that tiny fraction of cases, it would be highly debatable whether we could justify adding another layer of complexity into the language. In those rare occurrences where named parameters have true benefits, please live with the drawbacks of using array(). Zeev At 09:17 15/01/2006, Aidan Lister wrote: >Ron Korving wrote: > > […] > >We've seen a large number of cases where named parameters would be >extremely useful. To each case, there has been a half baked attempt >to dismiss the usefulness of the purported design. > >For example, > > […] > >Refactor? If you have a number of required options to get a result, >refactoring isn't going to change that. > >Also, > > […] > >That's not the point, at all. It annoys me that good points are >being dismissed with such ridiculous counter-arguments. > >No one is suggesting that people shouldn't look at the definition. >Nor that people have problems remembering parameter order (I do, but >again, not the point). In fact, named parameters allows people to >quickly look at the definition to see what options are available. >This is one reason named parameters are an improvement on >associative array parsing. > >The problem is when an option needs to be changed which just happens >to be at the very end of the function signature, function calls >start looking like this: foo(null, null, null, null, null, null, true); > >Anyway, enough rebuttal. I think it's now incredibly obvious that >the wider community would like to see named parameters in PHP 6. > >Are the PHP group prepared to accept and implement a named parameters patch? --- ## #21537 — Rasmus Lerdorf — 2006-01-15T10:37:01+00:00 URL: https://externals.io/message/21488#21537 · In reply to: #21535 Zeev Suraski wrote: > At 09:51 15/01/2006, Rasmus Lerdorf wrote: > > […] > > As Andi said, that's hardly the big issue (we could have provided it as > a userland feature, not applicable to internal functions, or applicable > to just a small subset of them). > > The big issue is whether or not we want that feature in the language, > and the answer appears to be no. Well, having half of a feature like that by only making it work in some places is what I think many folks are against. I don't think the answer is no if we had a clean and consistent way to implement it. I would certainly be all for it in that case. -Rasmus --- ## #21538 — Derick Rethans — 2006-01-15T11:17:45+00:00 URL: https://externals.io/message/21488#21538 · In reply to: #21533 > Aidan Lister wrote: > > […] > > As far as I am concerned it would depend on the patch. If you can come up > with a way to do it with requiring rewriting all 4000+ functions out there, go ^^^^ I think you meant without? Derick --- ## #21539 — Zeev Suraski — 2006-01-15T12:00:49+00:00 URL: https://externals.io/message/21488#21539 · In reply to: #21537 At 12:37 15/01/2006, Rasmus Lerdorf wrote: >Zeev Suraski wrote: > > […] > >Well, having half of a feature like that by only making it work in >some places is what I think many folks are against. I don't think >the answer is no if we had a clean and consistent way to implement >it. I would certainly be all for it in that case. Ok, so we're split. I actually don't think it's a must to have all functions adhere to this new method of calling (I don't think it's necessary, but even if it was - it's probably just a few days of work). It's definitely not the implementation which is the problem, as with other cases, we have enough bright people on board here that could figure it out if we wanted to go ahead with it. It's adding another core level feature that's useful in very rare cases, and that adds another layer of complexity, that is the problem in my (and many others') opinion. And it becomes even much worse if we support it throughout the entire language, as it means it'll become popular not only in these rare cases where it's really useful, but throughout everyday usage (as is the case with about anything, some people prefer one way of doing things, and others prefer another). Thankfully, regardless of the reasoning, the bottom line is no. Zeev --- ## #21542 — Ron Korving — 2006-01-15T13:49:38+00:00 URL: https://externals.io/message/21488#21542 · In reply to: #21539 Zeev, I agree with you that if this is implemented throughout the engine, it would actually not make things better. Some people will be doing strpos(needle: $needle, haystack: $haystack) and others will be doing strpos($haystack, $needle) and PHP will grow to a situation where half the people are doing A and half the people are doing B. I fear that would be very much for the worse. So, personally, I've come to the conclusion that it would be best if it existed as a userland feature only that people can use for those occasions where it might actually be useful. - Ron "Zeev Suraski" wrote in message news:7.0.1.0.2.20060115135052.05c1b848@zend.com... > At 12:37 15/01/2006, Rasmus Lerdorf wrote: > > […] > > Ok, so we're split. I actually don't think it's a must to have all > functions adhere to this new method of calling (I don't think it's > necessary, but even if it was - it's probably just a few days of > work). It's definitely not the implementation which is the problem, > as with other cases, we have enough bright people on board here that > could figure it out if we wanted to go ahead with it. > > It's adding another core level feature that's useful in very rare > cases, and that adds another layer of complexity, that is the problem > in my (and many others') opinion. And it becomes even much worse if > we support it throughout the entire language, as it means it'll > become popular not only in these rare cases where it's really useful, > but throughout everyday usage (as is the case with about anything, > some people prefer one way of doing things, and others prefer another). > > Thankfully, regardless of the reasoning, the bottom line is no. > > Zeev --- ## #21548 — Brian Moon — 2006-01-15T17:38:40+00:00 URL: https://externals.io/message/21488#21548 · In reply to: #21542 > PHP will grow to a situation where half the > people are doing A and half the people are doing B. I fear that would be > very much for the worse. Where were all these arguments when PHP was changed to become Java Jr.? I agree that if implemented this feature should be all or nothing. If its only userland, it is confusing to new users. But, I really to find it upsetting to see so many people saying that this feature will fracture the PHP community. Those with CVS access have already put things (like all the OO functionality) in that have fractured the user base already IMO. Brian Moon Phorum Dev Team --- ## #21549 — Gareth Ardron — 2006-01-15T18:05:23+00:00 URL: https://externals.io/message/21488#21549 · In reply to: #21548 Brian Moon wrote: > > […] > > I agree that if implemented this feature should be all or nothing. If > its only userland, it is confusing to new users. But, I really to find > it upsetting to see so many people saying that this feature will > fracture the PHP community. Those with CVS access have already put > things (like all the OO functionality) in that have fractured the user > base already IMO. Oh come on. OO was needed if php was ever to be taken seriously as an enterprise ready language. You can't however do everything in OO, so you need to learn procedural anyway - so all the userbase still knows procedural. --- ## #21563 — steve — 2006-01-18T02:08:46+00:00 URL: https://externals.io/message/21488#21563 · In reply to: #21536 > In those rare occurrences where named parameters have true benefits, > please live with the drawbacks of using array(). I do, though code completion, type hinting, etc. would be nice. It would nice if it was consistenly added so that built-in functions had that behavior, since no one can use the array hack for those. But lots of things would be nice, so I don't really care. Seems like too much work for the benefit. And there are downsides not even mentioned in this thread (parameter names are now seen (which is obvious, until you really think about it), they gain longevity, language issues, etc.). Not to mention, we might be tempted to go back and rewrite stuff and that would not be an effecient use of our time. But "rare occurrences"? That was pretty funny! Sadly... --- ## #21564 — Jeremy Johnstone — 2006-01-18T07:48:01+00:00 URL: https://externals.io/message/21488#21564 · In reply to: #21563 Just to throw in my two cents since every one else has (not that my 2 cents is worth anything more than just that), but isn't it as easy as doing something like the following: (using pseudo example from above) function db_connect($params) { $host = 'localhost'; $user = 'root'; $password = ''; $port = 3301; extract($params, EXTR_OVERWRITE); // ... more code here } This covers the default parameters in a clean fashion which is easy to understand and should be readable to anyone who knows PHP in even the slightest fashion. Now to the issue of type hinting, it's as simple as doing something like the following: if(!($obj instanceOf ClassName)) { throw new Exception(); } Then you have complete control of how the error is handled (be it exceptions, `trigger_error()`, etc). To me, it seems the options are a LOT more flexible using array syntax than using actual named parameters, but maybe that's just me. To each their own, but if it were me, it seems the above not only is easier to use / read, but also guaranteed to work on almost all versions of PHP (at least in the case of the first code snippet). -- --------------------------- Jeremy Johnstone http://www.jeremyjohnstone.com jsjohnst@php.net --- ## #21574 — Xenon_54 — 2006-01-19T04:09:19+00:00 URL: https://externals.io/message/21488#21574 · In reply to: #21564 > Just to throw in my two cents since every one else has (not that my 2 > cents is worth anything more than just that), but isn't it as easy as > doing something like the following: > > (using pseudo example from above) > > function db_connect($params) { > $host = 'localhost'; > $user = 'root'; > $password = ''; > $port = 3301; > extract($params, EXTR_OVERWRITE); > // ... more code here > } > > This covers the default parameters in a clean fashion which is easy to > understand and should be readable to anyone who knows PHP in even the > slightest fashion. I think you should use `EXTR_IF_EXISTS` instead of EXTR_OVERWRITE. I guess you don't want undefined arguments to be defined by the user. Just adding my 2 cents too.