# RFC Skipping optional parameters for functions - Thread: https://externals.io/message/60678 - Original archive: https://news-web.php.net/php.internals/60678 - Started by Mathias Grimm on 2012-05-27T17:27:08+00:00 - Messages: 6 - 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 --- ## #60678 — Mathias Grimm — 2012-05-27T17:27:08+00:00 URL: https://externals.io/message/60678#60678 in response to https://wiki.php.net/rfc/skipparams I want to suggest something as depicted below: function very_long_params(name:$n, age:$a, other:$o) { } or function very_long_params(:name = null, :age, :other) { $name = trim($name); ... } $result = very_long_params(age:20, other:'foo', bar:$tmp); just be paramaters named, like array, allowing too the order swapping on call -- Mathias Grimm --- ## #60679 — Daniel Macedo — 2012-05-27T18:03:28+00:00 URL: https://externals.io/message/60678#60679 · In reply to: #60678 NOTE: Although related/solving some of the same problems; skipping optional parameters (several commas or using 'default' keyword) is different from using named parameters. And both have different supporters/haters over each change. I wouldn't like to restart the whole debate over the KISS, "Not the PHP way", or the alternate ways work around the original issue. But on a personal opinion, I'd like to see named parameters implemented - which also solves the skipping optionals regardless of the order - the only concern of the community at large might be the proper syntax.. I also suggested the even shorter array syntax for 5.4: http://php.net/migration54.new-features Which would use the colon as a separator $a = ['one': 1, 'two': 2, 'three': 3, 'four': 4]; And the idea it would be simpler/efficient/readable inspired some dissent over both the readability and the PHP-way. So I'm not sure if your suggestion won't keep the same issue... --- ## #60680 — Mathias Grimm — 2012-05-27T18:28:13+00:00 URL: https://externals.io/message/60678#60680 · In reply to: #60679 Named parameter in the same way that goto does, with labels. A labeled parameter... But there always some drawbacks... such as mix named and conventional parameters. I think that you just chose one way and use, not allowing mix these two ways. I also think that should exists a strict way to write code, something like error_reporting, but to ensure a specific way to write code, gaining speed in the whole compilation thing. strict_code_standard = K&R strict_code_standard = GNU strict_code_standard = PEAR strict_code_standard = ZEND The GO land does it in some way > > NOTE: Although related/solving some of the same problems; skipping optional parameters (several commas or using 'default' keyword) is different from using named parameters. > And both have different supporters/haters over each change. > > I wouldn't like to restart the whole debate over the KISS, "Not the PHP way", or the alternate ways work around the original issue. > > But on a personal opinion, I'd like to see named parameters implemented - which also solves the skipping optionals regardless of the order - the only concern of the community at large might be the proper syntax.. > > I also suggested the even shorter array syntax for 5.4: http://php.net/migration54.new-features > Which would use the colon as a separator > $a = ['one': 1, 'two': 2, 'three': 3, 'four': 4]; > > And the idea it would be simpler/efficient/readable inspired some dissent over both the readability and the PHP-way. > > So I'm not sure if your suggestion won't keep the same issue... -- Mathias Grimm --- ## #60681 — William Betts — 2012-05-28T01:14:17+00:00 URL: https://externals.io/message/60678#60681 · In reply to: #60680 On Sun, May 27, 2012 at 11:28 AM, Mathias Grimm wrote: > Named parameter in the same way that goto does, with labels. A labeled > parameter... > But there always some drawbacks... such as mix named and conventional > parameters. I think that you just chose one way and use, not allowing mix > these two ways. > > goto a; > echo 'Foo'; > > a: > echo 'Bar'; > ?> > > > I also think that should exists a strict way to write code, something like > error_reporting, but to ensure a specific way to write code, gaining speed > in the whole compilation thing. > > strict_code_standard = K&R > strict_code_standard = GNU > strict_code_standard = PEAR > strict_code_standard = ZEND > > The GO land does it in some way > I can see how enforcing a strict coding standard would be useful, but only if you're also allowed to define your own. --- ## #60682 — Kris Craig — 2012-05-28T01:18:05+00:00 URL: https://externals.io/message/60678#60682 · In reply to: #60681 On Sun, May 27, 2012 at 6:14 PM, William Betts wrote: > On Sun, May 27, 2012 at 11:28 AM, Mathias Grimm > […] > > > […] > like > > […] > speed > > […] > > I can see how enforcing a strict coding standard would be useful, but only > if you're also allowed to define your own. > I'm intrigued about the notion of having the option to use named parameters in function calls/declarations. Aside from the obligatory, "Changing anything in PHP would be too confusing!" complaint, what would be the primary argument(s) against this? --Kris --- ## #60685 — Stas Malyshev — 2012-05-29T00:29:29+00:00 URL: https://externals.io/message/60678#60685 · In reply to: #60678 > in response to https://wiki.php.net/rfc/skipparams I want to suggest > something as depicted below: > > function very_long_params(name:$n, age:$a, other:$o) The goal of this proposal is not to introduce named parameters. If we ever do introduce named parameters, the names will probably be the same as variables, and would use $ as the rest of PHP variables do. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227