Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78490
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <DCF8CAF9-2A97-455C-8564-6534DCFB3035@ajf.me>
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com>
	<CABRjmp9p=+zGiqn_nuVJcDAK0po98FnDhb7wTmG66tob4u0GOw@mail.gmail.com>
	<CAL+t6cFh77D0FufKGy_OeLO7O0=ky46Zv8S=oTLFP8VnZRtCvw@mail.gmail.com>
	<36B5E957-01C0-40F2-B4CE-5B02D11ACA14@ajf.me>
	<CAL+t6cGERpWQDSmqfHVYgb4hzKOtFaKWPKt2Lvm44FNyoE-ebg@mail.gmail.com>
	<DCF8CAF9-2A97-455C-8564-6534DCFB3035@ajf.me>
Date: Thu, 30 Oct 2014 16:49:58 -0400
Message-ID: <CAL+t6cHE8Ye+r4uJsO-UdtHTEGP7=kwvEzrnp8_Q4rmEn-p0MA@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Florian Margaine <florian@margaine.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c34160fbad110506aa055b
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: theanomaly.is@gmail.com (Sherif Ramadan)

--001a11c34160fbad110506aa055b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 30, 2014 at 4:42 PM, Andrea Faulds <ajf@ajf.me> wrote:

>
> > On 30 Oct 2014, at 20:33, Sherif Ramadan <theanomaly.is@gmail.com>
> wrote:
> >
> > Yes, this proposal is intended to do two things. 1) Fix the
> aforementioned problems.
>
> By the sounds of things, it doesn=E2=80=99t fix these problems, it just a=
dds a new
> interface which lacks them. That=E2=80=99s not the same thing.
>
>
No, the interface makes it possible to implement your own behavior, but it
does not prevent PHP from implementing default behavior. In that PHP would
implement its own HttpRequest class, for example, which the user can then
extend to override default behavior or modify it as they see fit for their
particular use case. This is much like the Session interface, which makes
it possible to change session storage mechanisms in userland, but still
have a confirming method of session handling in PHP.


> > 2) Improve upon the capabilities of PHP's request handling for future
> use cases through a unified interface.
>
> What unified interface? You=E2=80=99re allowing anyone and everyone to im=
plement
> their own request handling.
>

Yes, by allowing this you make it extensible. However, having the interface
is what makes it possible to unify the efforts of dealing with the HTTP
messages both in userland and in PHP internals.


>
> > If you consider all of the major existing PHP frameworks today there is
> always some form of HttpRequest class handling these things and almost al=
l
> of them do it slightly differently. What's worse, is they are all very
> inefficient implementations that I believe can be done far more efficient=
ly
> in php-src. A lost of them are also unnecessarily complex. I think all of
> this can be simplified if the interface is just laid out in a
> straight-forward manner and then userland implementations will find less
> and less reason to over-engineer the implementation.
>
> The only reason an implementation of HttpRequest would be inefficient is
> because it has to work-around problems with $_GET and $_POST. Problems we
> could simply fix.
>

So the fix to something like PUT/DELETE requests is to add yet another
superglobal. However, this is still a very rigid fix that requires
continuous maintenance and fulfilling feature requests on the part of
internals. Think of implementing a new session handler for every session
storage mechanism in PHP. This is a lot of unneeded effort when we can just
expose the session interface to userland and make it extensible by nature.
The alternative is far more useful and less closed up (preventing future
problems to fix).

Let's not also ignore the fact that such features have been forsaken by PHP
internals for years. I have bug reports dating back to 2010 that have asked
for such features that have long been unanswered. So the current desire to
fix anything along these lines appears to be minimal, if not non-existent,
right now.


>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>

--001a11c34160fbad110506aa055b--