On 10/31/14, 12:38 PM, Sherif Ramadan wrote:
On Fri, Oct 31, 2014 at 1:32 PM, Florian Margaine <flor...@margaine.com>
wrote:
Hi,
Le 31 oct. 2014 18:28, "Sherif Ramadan" <theanomaly...@gmail.com> a écrit
:
On Fri, Oct 31, 2014 at 1:09 PM, Rowan Collins <rowan.coll...@gmail.com>
wrote:
Let me repeat my question:
Say I write a class "AwesomeHTTPReceive implements HttpMessageReceive",
what do I then do with this class in order for it to perform any
actions?
How does PHP know that my class is the one it should populate, or when
that population should happen?
It wouldn't. You would need to extend the base class, since it already
implements the necessary interface. PHP would simply call on the last
subtype of HttpRequest during the request init phase.
What if there is multiple subtypes?
class A extends HttpRequest {}
class B extends HttpRequest {}
What happens there?
As of now, all the subtypes would be called, i.e. if A has a receiveMessage
method, it would be handed the message, and if B has a receiveMessage
method it too would be handed the message. It's up to those methods to call
on subsequent parsing methods to do something with the message, obviously
any methods they don't implement are forwarded to the parent.
This clearly has some conflicts, like if default parsing is left we
overwrite superglobal variables. However, it also has benefits, in that we
can have multiple implementations for handling the request in the same code
base and it is left up to the user to decide which one to use.
So, again, this is still a draft and I'm open to suggestions about how to
handle/deal with such problems.
I think the root problem is that you're solving an issue that doesn't exist.
You're talking about providing alternate ways to parse the raw HTTP
stream into user-accessible variables, ie, by pushing them into an
object of a known interface rather than/in addition to the superglobals.
In my 15 years of writing PHP I have never wanted to change the way the
raw HTTP is parsed. I have, however, frequently wanted to have the data
accessible in a more logical, semantic, and HTTP-correct way. ($_GET is
not about HTTP GET, it's about URI query parameters. $_POST isn't about
HTTP POST, it's about application/x-www-form-encoded. Etc.) And I've
wanted that information available in a non-global, OOP-injectable way.
But I've never once had any desire to change the way an
application/x-www-form-encoded is parsed.
Implementation problems aside, your proposal is not solving an extant
problem.
If we want to improve PHP's HTTP handling, then having an object that
exposes the HTTP request in a more logical fashion would be far more
useful, and/or providing that data in a more logical way so that someone
in user-space can provide that data in a logical fashion (eg, via a
PSR-7-implementing object.) I already stated in an earlier email what I
felt would be most beneficial for internals to do toward that goal
(specifically, clean up the streams API so that we can use it directly
from an OOP world rather than a 1980s C world.)
IF internals wanted to add implementation, not just improving streams,
something like the following would be much more useful:
$request = http_get_request(PHP_STDIN); // or something
Where $request is an object that implements the PSR-7 RequestInterface
(or at least the read-only parts of it), or something similar. Then
implementers can compose that object however they want.
Although at least for the near term I think it's better to not do that
and just do the lower-level plumbing to make FIG's work with PSR-7 easier.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
