Re: [RFC] Bug #72811 - Replacing parse_url()

On 10/07/2016 09:45 AM, David Walker wrote:

I think an important part of this interface is that the URL is constructed using URL(url [, base]), where "base" is the base URL against which relative URLs are resolved. This base URL is required for parsing non-absolute URLs. To me this makes a lot of sense and I think it makes it much clearer how "incomplete" URLs are being treated.

If we go the route of making URL it's own object, and expose an object-oriented interface, are we leading it to be more of a total URL builder, of sorts? Like: $url = new URL(); $url->setScheme('http'); $url->setHost('example.org'); $url->setPath('/test.php'); var_dump($url->build()); // outputs: http://example.org/test.php OR, would it, at the end of the day be an object that takes a string, and you just call getter's on it that would be akin to the current flags you pass into parse_url()? On both accounts, if we're to go forward with the Object model of URL, would this want to be broken into it's own ext/url module, like how date exists? Or retain it in ext/standard? Cheers -- Dave

Be aware that a user-space definition for a URL object already exists as part of PSR-7: http://www.php-fig.org/psr/psr-7/#3-5-psr-http-message-uriinterface A core-provided mutable and incompatible object would be problematic. What would be useful would be to have a C-level function (parse_url() or otherwise) that can generate a very well-known and standardized array structure (ie, better than parse_url()s now) that a UriInterface implementation could trivially wrap. Basically, a way to simplify this existing code: https://github.com/zendframework/zend-diactoros/blob/master/src/Uri.php#L435 And move the conditionals and filter*() sub-calls to C. (Right now they play games with regexes and hope.) --Larry Garfield