Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96282
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain brzuchalski.com designates 188.165.245.118 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CABdc3WpA8JQHE=sOWsBiRB0LA=cT1CUUss+6gTKCSkGXyw8+YQ@mail.gmail.com>
References: <CADVQu1QYkLGowNGVohfRvYWc=8N7tWfcjghOT0Zvx0_PuJSDYw@mail.gmail.com>
 <fa578fe5-6069-bc02-253e-ba849215a87a@gmx.de> <CADVQu1S5MDMqZRBovrMM94_=qyLvM5dkH_K4DwQJEx66mKruFQ@mail.gmail.com>
 <F3741613-1E6C-4978-8284-9EB505A46F2A@koalephant.com> <CADVQu1QLUs1PnbFo3=Hh3H3_1i_Hzso82So5WT74wz3jQ+8OLw@mail.gmail.com>
 <CADyq6sLWgoAPKTiqLLNVP4ECs15dQSvLKL12tanMfMVhDUYfvg@mail.gmail.com> <CABdc3WpA8JQHE=sOWsBiRB0LA=cT1CUUss+6gTKCSkGXyw8+YQ@mail.gmail.com>
Date: Fri, 7 Oct 2016 11:47:19 +0200
Message-ID: <CABdc3Wo9S9cNVebZfy4rPWy091p5EEwWjjRU11tjXiGkQwHjsA@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: David Walker <dave@mudsite.com>, Stephen Reay <php-lists@koalephant.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11488730d80e7f053e434b30
Subject: Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()
From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--001a11488730d80e7f053e434b30
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2016-10-07 11:21 GMT+02:00 Micha=C5=82 Brzuchalski <michal@brzuchalski.com>=
:

> How about complete rewrite with OOP? It could be implemented using Object=
s
> 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=3D1&arg1=3D2` as an array, PHP parses only=
 last,
> * `?arg1[]=3D1&arg1=3D3` some parses adding element 3 to "arg1" array som=
e
> replaces)
>
> This implementation also supports UriTemplates ("
> http://localhost/{module}/action") and UriReferences
> ("/some/reference?arg1=3D2#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 futur=
e
>> > scope could be to look at filter_var() and how it uses that filter typ=
e.
>> > 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 cod=
e
>> 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=C5=82 Brzuchalski
> brzuchalski.com
>



--=20
regards / pozdrawiam,
--
Micha=C5=82 Brzuchalski
brzuchalski.com

--001a11488730d80e7f053e434b30--