On 02/11/2014 09:46, Lester Caine wrote:
The current discussion on http response objects and other aspects of the transmission process has brought out a few more 'what the ...' from some of you and as with a lot of the 'modern' discussions, the reasons for wanting something tend to be wrapped in a lot of assumptions that the rest of us understand exactly what is being discussed. In many cases I'll be frank - despite starting programming back in the early 1970's much of the debate goes over my head!
I think there's a good point here, that we need to make sure - particularly in the core of the language - that we maintain PHP's long-standing support for writing quick, unstructured programs, without a lot of boilerplate.
Ideally, new use-cases which are difficult or awkward with current functions would be supported by simply adding new functions in the same style as those that already exist. However, PHP's standard library of functions is notoriously inconsistent, so the right way to add such new functionality isn't always obvious, and sometimes doing so would just add to existing confusion or complexity. In such circumstances, it is sometimes right that we look at designing a new API which overlaps with the old; if this can be done in such a way that the new API is still simple for the simple cases, all the better, but if not, the old API needs to be maintained as more than just a begrudging compatibility shim.
The superglobals for HTTP requests are probably a good example of this: we definitely need to keep them for compatibility reasons, but further than that we mustn't start thinking of them as inferior or deprecated if their replacement requires an additional 10 lines of boilerplate to be added to every 1-page PHP script.
As for PHP-FIG, its mission is rather different - for those people who are writing framework-based applications, and modules designed to be used by those applications, it is useful to have a set of agreed conventions ("Recommendations") to work with. Some of these are basically just arbitrary choices, like agreeing whitespace conventions so that code shared from one project to another doesn't look out of place. Others can be useful even for smaller projects - for instance, if you intend to pass around a logger object, you can make it implement PSR-3, making it trivial to switch over to a third-party library like Monolog if you later decide that would be beneficial.
-- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
