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