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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
