On Fri, 2013-10-04 at 20:38 +0200, Christian Stadler wrote: > Actually I like the idea of having an API to handle everything important > for the HTTP-request and respectively for the response. > > e. g.: > HTTPRequest::getFormData(...), which could possibly be aliased by > HTTPRequest::getPOSTData(...) or HTTPRequest::getPOST(...);
We have filter_input(INPUT_POST, ...); > as well as > HTTPRequest::getQueryData(...) aliased by > HTTPRequest::getGETData(...) or HTTPRequest::getGET(...); We have filter_input(INPUT_GET, ...); > and HTTPRequest::filterXXX(...) as a replacement for filter_var() > and so on Why replace something? Are there flaws which can't be fixed? Adding too many ways to do the same thing is confusing for everybody. If you want it "object oriented" or such frameworks do great things. The language should offer a good foundation. (It is my strong believe that we should move as many "high level" things as possible in libraries) > HTTPResponse could include a replacement for htmlspecialchars and > htmlentities (not quite sure, if this fits better to HTTPRequest or > probably into both) > HTTPResponse::buildQuery() would be a replacement für http_build_query > and so on. > > To make a long story short: IMHO Every function and superglobal related > to the HTTP-request or -response should be moved to their respective > classes so eveything is under one hood rather than making userland > guessing which function/superglobal/whatever is for what purpose. > As it is now, it is kinda chaotic and confusing to me and probably to > userland, too. Some of these things might have been named better, back in the past, but I see no benefit in making those static methods in classes, except maybe that we then need two hash lookups (class and method tables) instead of one (function table). And btw. that design from above already is flawed too: HTTPResponse::buildQuery() - this has nothing to do with an HTTP responses. This is i.e. also needed for some stream operations. And also the escaping is not needed for HTTP, but HTML, even when creating static HTML pages. ;-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
