On 10/13/2016 10:00 AM, David Walker wrote:
On Mon, Oct 10, 2016 at 1:22 PM Larry Garfield <la...@garfieldtech.com>

Be aware that a user-space definition for a URL object already exists as
part of PSR-7:


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:


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

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.


It's not that having an RFC-compliant parser in C is problematic. Quite the opposite. It's the representation it produces back to user-land code. Viz, right now the most common PSR-7 implementation uses parse_url() internally, which as noted is somewhat buggy and incomplete. If PHP natively provided a better parser that a PSR-7 implementation could use, that's good for everyone.

What would not be helpful is for PHP to natively provide, essentially, a competitor to PSR-7's Uri object. The raw data parsing can/should live in C, while the main user-space representation is defined in user-space. That's the same point that was made for HTTP headers overall a while back; PHP already has the ability in C to read a stream and parse it out into headers, a GET array, a POST array, etc. It uses it for the super-globals. Exposing that capability to user-space would allow for more efficient and flexible implementations of PSR-7 or similar.

I fully expect that in a few years PSR-7 will be updated and supplanted with something that leverages newer PHP features, and we would want to make that transition as smooth as possible. That means having a clear stack of complementary functionality, not competing "polished" functionality that would then have to be mapped back and forth in a clumsy fashion.

--Larry Garfield

PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to