Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115647
To: internals@lists.php.net
References: <7DA18959-3463-4AAE-ABE3-B9330FEE83D2@gmail.com>
 <CAGBsUrfoAT4CeiJvbNDczjiqRLLikdvmCfYe2BdUQDZudZ2w4w@mail.gmail.com>
 <f45b55bd-1ce6-4e28-9eda-13c2603c8eb2@www.fastmail.com>
Message-ID: <cd281c28-f380-29e2-7393-c08012afda1f@gmail.com>
Date: Fri, 6 Aug 2021 16:59:05 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <f45b55bd-1ce6-4e28-9eda-13c2603c8eb2@www.fastmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Re: [RFC] Add parse_query_string as an alternative to
 parse_str
From: rowan.collins@gmail.com (Rowan Tommins)

On 06/08/2021 16:06, Larry Garfield wrote:
> Give me a properly defined HttpQuery object with named, type-enforced properties and meaningful methods.  Give it a parse(string) static method and a __toString() method to convert back to a query string.  Anything less is, frankly, not worth the effort.


While I understand your general principle, I'm not sure what such an 
object would look like. There is no "standard list" of query string keys 
which could be named as properties on a built-in HttpQuery object; every 
request is different, so the user would have to provide the object to be 
"hydrated" in some form.

Maybe it would have to be a trait, so you could write something like this?

class GetUserQueryParams {
     use HttpQueryParser;
     private ?int $id;
     private ?string $name;
}
$params = GetUserQueryParam::fromQueryString('?id=42');

Or a utility method that took a class name, and converted the query 
string parameters to named constructor arguments?

class GetUserQueryParams {
     public function __construct(
        private ?int $id,
        private ?string $name
    ) {}
}
$params = parse_query_string('?id=42', GetUserQueryParams::class);


Once you've started down that route, people will want a way to alias 
property names (e.g. with attributes), have parallel handling for other 
formats like JSON ... and before you know it you have the kind of 
complexity which is much easier to manage as a userland library than 
something tied to core.

On the other hand, if core provides a sane implementation of the parsing 
into a generic "bag of key-value pairs" (which PHP calls an "array"), 
that would provide a very useful building block for any userland library 
to build on.


Regards,

-- 
Rowan Tommins
[IMSoP]