Hi All, Johannes Schlüter wrote (on 07/10/2013):
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)
I think this is a strong point: PHP as it is now is a long way from being usable as a modern framework in its own right, and building a framework-like API for this kind of functionality may open a bigger can of worms than was intended. Zend, Symfony, et al have a massive head-start on any kind of "PHP native framework".
Rather than trying to build the framework logic into the core, how about exposing the functionality currently in core to user-space so that frameworks can wrap it more efficiently? Looking around, we currently have the slightly awkward parse_str for query strings and application/x-www-form-urlencoded bodies; I imagine there's something in pecl_http for multi-part/form-data, but I'm not familiar with that extension, and it's not part of core.
If the internal implementations were decoupled from the population of $_POST as a consistent set of functions, frameworks could simply wrap them alongside custom parsers such as JSON (with appropriate options) or XML (restricted to some framework-defined schema). This also allows for simulated requests, unit testing, etc, and passing in file_get_contents('php://input') should allow parsing any request body. If this was done as some consistent "serialization/deserialization" module, it could expose the session serialization formats as well, replacing the horrible environment-clobbering of session_decode().
Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
