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

2016-10-07 11:21 GMT+02:00 Michał Brzuchalski <michal@brzuchalski.com>: > How about complete rewrite with OOP? It could be implemented using Objects > like DateTime does. > I've got working implementation in userland > https://github.com/madkom/uri it > maybe not be finished yet but supports parsing URI with IPv4, IPv6 and > Hostnames. > It was also going to parse query arguments from URI depending on how to > parse multiple arguments: > * some languages parses ?arg1=1&arg1=2 as an array, PHP > parses only last, > * ?arg1[]=1&arg1=3 some parses adding element 3 to > "arg1" array some > replaces) > > This implementation also supports UriTemplates (" > http://localhost/{module}/action") and UriReferences > ("/some/reference?arg1=2#fragment"). > My proposed impl supports parsing and building, I can see there is possible to move functionalities from few global functions into one OO written package. > > 2016-10-07 8:38 GMT+02:00 Marco Pivetta <ocramius@gmail.com>: > >> On Fri, Oct 7, 2016 at 8:32 AM, David Walker <dave@mudsite.com> wrote: >> >> > On Thu, Oct 6, 2016 at 10:13 PM Stephen Reay <php-lists@koalephant.com> >> > wrote: >> > >> > > Could the new URL parser be exposed via a third parameter to >> parse_url, >> > > which defaults to false/off in 7.2 (or whenever its added) but then >> > > defaults to true in 8.0? >> > >> > >> > I, personally, would be opposed to this. Firstly, it doesn't alert >> users >> > to the previous functionality being non-standards compliant. Secondly >> it >> > allows the previous parser to exist in it's current state for a longer >> > period of time, then in 8.0 exist as a function parameter. The goal >> should >> > be to drop the standards-uncompliant version at some point. >> > >> > >> > > Additionally, would(could) this same url parser be used for >> > > FILTER_VALIDATE_URL, which currently states (in the docs) that it >> matches >> > > RFC2396, and indeed it appears not to accept an IPv6 host segment. >> > > >> > >> > I haven't yet looked at to how filter validation exists in conjunction >> with >> > parse_url(), however as noted ( >> > >> > http://php.net/manual/en/filter.filters.validate.php#110411) the >> > FILTER_VALIDATE_URL, may be strict to URL's not URN's. Maybe, a future >> > scope could be to look at filter_var() and how it uses that filter type. >> > Maybe could add a proper FILTER_VALIDATE_URI, or something. >> > >> > However that would be outside the scope of this RFC for right now, I >> > believe. >> > >> > -- >> > Dave >> > >> >> Like with any software rewrite project, remember that software rewrites >> usually fail. >> >> It's probably better to deprecate the function, make a new one, then code >> the newer implementation there, and let users migrate. >> >> This is necessary to mitigate the risk of BC breaks. >> >> Marco Pivetta >> >> http://twitter.com/Ocramius >> >> http://ocramius.github.com/ >> > > > > -- > regards / pozdrawiam, > -- > Michał Brzuchalski > brzuchalski.com > -- regards / pozdrawiam, -- Michał Brzuchalski brzuchalski.com