Re: RFC: Server-Side Request and Response Objects (v2)

From: Date: Fri, 14 Feb 2020 15:47:25 +0000
Subject: Re: RFC: Server-Side Request and Response Objects (v2)
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-108581@lists.php.net to get a copy of this message
Hi Côme & Niklas, > On Feb 13, 2020, at 04:52, Côme Chilliet <come.chilliet@fusiondirectory.org> wrote: > > Le mercredi 12 février 2020, 19:20:56 CET Niklas Keller a écrit : > >> Naming >> >> I think we shouldn't take over the naming of the super globals, e.g. >> $_GET really contains the query parameters and has nothing to do with >> GET or POST, so $request->getQueryParameter(...) would be a better >> name. > > I think this remark is really on point. > GET and POST are HTTP methods and not ways of passing data. You can have query parameters on > any request, and you can have POST data with a lot of other HTTP methods, as is commonly used in > REST APIs. Your comments on naming are well-made. While working on the implementation, we tried out $query instead of $get, on exactly the premise that you state: i.e., that $_GET holds the query parameters, and has nothing to do with the GET method. But in the end, we settled on mapping more directly from $_GET => $get, and $_POST => $post. Having said that, we are willing to revisit that naming decision if there's support for doing so. Perhaps: - rename $get to $query, populating it from $globals['_GET'], on the basis stated above - rename $post to $input, populating it from $globals['_POST'], on the basis that it typically relates to the parsed form of php://input Your (and/or anyone else's) thoughts on that? -- Paul M. Jones pmjones@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php

« previous php.internals (#108581) next »