# Named params status - Thread: https://externals.io/message/72733 - Original archive: https://news-web.php.net/php.internals/72733 - Started by Gleb Golubitsky on 2014-02-21T12:10:00+00:00 - Messages: 12 - 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 --- ## #72733 — Gleb Golubitsky — 2014-02-21T12:10:00+00:00 URL: https://externals.io/message/72733#72733 Hello guys, What is the current status of the named params implementation (RFC [1])? According to RFC it's under discussion and proposed for 5.6 release. Can we really expect this feature in 5.6 release? The change will provide the great boost of code readability. Looking forward for reply. -- WBR, Gleb Golubitsky AKA Sectoid Jabber ID: sectoid@gnolltech.com --- ## #72735 — Gleb Golubitsky — 2014-02-21T12:20:40+00:00 URL: https://externals.io/message/72733#72735 · In reply to: #72733 > What is the current status of the named params implementation (RFC [1])? Forgot the link to the actual RFC. [1] - https://wiki.php.net/rfc/named_params -- WBR, Gleb Golubitsky AKA Sectoid Jabber ID: sectoid@gnolltech.com --- ## #72745 — Christopher Jones — 2014-02-21T19:46:53+00:00 URL: https://externals.io/message/72733#72745 · In reply to: #72733 > Hello guys, > > What is the current status of the named params implementation (RFC [1])? > According to RFC it's under discussion and proposed for 5.6 release. Can we > really expect this feature in 5.6 release? The change will provide the great > boost of code readability. > > Looking forward for reply. > It won't be in PHP 5.6. There's no timeline for it that I've seen. There are various discussions that show the project still has supporters. Chris -- christopher.jones@oracle.com http://twitter.com/ghrd Free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html --- ## #72747 — Gleb Golubitsky — 2014-02-21T19:49:08+00:00 URL: https://externals.io/message/72733#72747 · In reply to: #72745 > > […] > > It won't be in PHP 5.6. There's no timeline for it that I've seen. Sad to hear so. What exactly stops from having it in the mainline? > There are various discussions that show the project still has supporters. And can I help somehow with getting this changes up and merged? WBR, Gleb Golubitsky AKA Sectoid Jabber ID: sectoid@gnolltech.com --- ## #72756 — Mark Tomlin — 2014-02-22T09:20:34+00:00 URL: https://externals.io/message/72733#72756 · In reply to: #72747 Also would LOVE to see this, it's a MASSIVE feature to have. Thank you for your time, Mark 'Dygear' Tomlin. > > > > > […] > > Sad to hear so. What exactly stops from having it in the mainline? > > > […] > > And can I help somehow with getting this changes up and merged? > > WBR, > Gleb Golubitsky AKA Sectoid > Jabber ID: sectoid@gnolltech.com --- ## #72760 — Andrea Faulds — 2014-02-22T14:25:07+00:00 URL: https://externals.io/message/72733#72760 · In reply to: #72747 > > Sad to hear so. What exactly stops from having it in the mainline? > While the named parameters implementation works, we'd need to update the function info headers for every single internal function, and make sure it matches the documentation. I think Nikita simply doesn’t have the time on his hands. -- Andrea Faulds http://ajf.me/ --- ## #72761 — Gleb Golubitsky — 2014-02-22T15:07:44+00:00 URL: https://externals.io/message/72733#72761 · In reply to: #72760 > > > […] > > While the named parameters implementation works, we'd need to update the > function info headers for every single internal function, and make sure it > matches the documentation. I think Nikita simply doesn’t have the time on > his hands. Can I help somehow with this task? I'm familiar with C and PHP development, but don't know PHP internals well (yet? :)). So if I can help - I'll do my best to speed up the process. -- WBR, Gleb Golubitsky AKA Sectoid Jabber ID: sectoid@gnolltech.com --- ## #72762 — Patrick Schaaf — 2014-02-22T16:15:20+00:00 URL: https://externals.io/message/72733#72762 · In reply to: #72760 On Saturday 22 February 2014 14:25:07 Andrea Faulds wrote: > > > […] > > While the named parameters implementation works, we'd need to update the > function info headers for every single internal function, and make sure it > matches the documentation. I think Nikita simply doesn’t have the time on > his hands. I know that I said it more nicely before.... That is stupidity. Just release the feature for user code (self-written functions and methods). Create a suitable variation of the internals function declaration macros that expresses "this function has been vetted for named parameter usage, and refuse to accept named parameters (FATAL) for any function not so vetted. Then let the internal function vetting proceed at whatever pace it takes, later. If you first wait for each and every internal (and extension?) function being converted, this will never happen. best regards Patrick --- ## #72763 — Kevin Ingwersen — 2014-02-22T21:42:48+00:00 URL: https://externals.io/message/72733#72763 · In reply to: #72762 Am Sa. Feb. 22 2014 17:15:20 schrieb Patrick Schaaf: > On Saturday 22 February 2014 14:25:07 Andrea Faulds wrote: > > […] > > I know that I said it more nicely before.... That is stupidity. > > Just release the feature for user code (self-written functions and methods). > > Create a suitable variation of the internals function declaration macros that > expresses "this function has been vetted for named parameter usage, and refuse > to accept named parameters (FATAL) for any function not so vetted. > > Then let the internal function vetting proceed at whatever pace it takes, > later. > > If you first wait for each and every internal (and extension?) function being > converted, this will never happen. > > best regards > Patrick I agree with that post. For most, we can just create our own wrapper functions untill the functions have a real named parameter implementation (has_named_params() ?). The named parameters can then be added from time to time over minimal releases (5.6.?). --- ## #72765 — Andrea Faulds — 2014-02-23T01:45:24+00:00 URL: https://externals.io/message/72733#72765 · In reply to: #72762 > I know that I said it more nicely before.... That is stupidity. > > Just release the feature for user code (self-written functions and methods). > > Create a suitable variation of the internals function declaration macros that > expresses "this function has been vetted for named parameter usage, and refuse > to accept named parameters (FATAL) for any function not so vetted. > > Then let the internal function vetting proceed at whatever pace it takes, > later. > > If you first wait for each and every internal (and extension?) function being > converted, this will never happen. I know. I asked Nikita about this on IRC about a month or two ago. I think he said he just didn’t want to deliver an incomplete feature? -- Andrea Faulds http://ajf.me/ --- ## #72766 — Pierre Joye — 2014-02-23T03:24:51+00:00 URL: https://externals.io/message/72733#72766 · In reply to: #72765 > > > I know. I asked Nikita about this on IRC about a month or two ago. I think he said he just didn’t want to deliver an incomplete feature? I totally agree with Nikita here. We can't really release named argument with internals function not being ported. Cheers, Pierre --- ## #72842 — pajousek@gmail.com — 2014-02-27T12:44:48+00:00 URL: https://externals.io/message/72733#72842 As a userland developer, I would love to see named parameters. They are IMHO a much better way to achieve optional parameters skipping than the "skipparams" RFC. Also the named parameters look more "future-compatible" if PHP ever added things like method overloading (which would be great, but that's for another discussion). As for the "majority of users don't want it implemented"; I would probably say otherwise, because most people I spoke with really MISS named parameters in PHP. Pavel Kouril > Andrea Faulds wrote: > > […] > > The RFC says that Nikita will not work on it if there is no demand. I am > seeing many people do want it but personally this is another large bloat > that I see little point to so should there not at least be some vote on > whether it IS worth Nikita's time if the majority of users don't want it > implemented? Having been through a major exercise bringing this under > control using array parameters for variable data I don't want to have to > start coping with yet another passing mechanism as third party libraries > 'adopt new practices'! > > Since this RFC also pulls in other RFC's should the whole roadmap on this be > part of the developing plan for PHP6? Deciding what areas are actually worth > people spending time on. Certainly if parameter names are to evolve to use > UTF-8 strings, this should be part of the development plan? > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk