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

On Mon, Oct 10, 2016 at 1:22 PM Larry Garfield <larry@garfieldtech.com> wrote: > 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.) > Hi Larry, I guess I'm not sure why having a RFC/WHATWG compliant parser would be problematic with regard to PSR-7. It would be the application developers responcibility to take a standardized output and populate their object that implements UriInterface. WHATWG does seem to mitigate the need of some of the filter*() calls, but certain ones would still desire to be application-specific. Although WHATWG does not specify that the URL object has a getAll()-esque method, it could be beneficial to have something that returns a structure similar to what parse_url() does today. It could also be beneficial to just have URL implement ArrayAccess so you wouldn't have to bother with getting a specific array back, and can just access what you need. -- Dave