> On Feb 15, 2020, at 3:01 AM, Larry Garfield <la...@garfieldtech.com> wrote: > > Data point: > > In PSR-7, the names used are: > > - queryParams: The query string values. > - parsedBody: The body of the message, converted to a meaningful value. If > the request type is a form, then it MUST be equivalent to $_POST. If not, > it's up to the particular implementation to determine what "parsed" means. > (Eg, parsing a JSON body of a POST into some domain object, or whatever.) > - The raw body is a stream called "body", or rather an OOP wrapper around a > stream since PHP's native stream interface is fugly. > - There's specific handling for uploadedFiles, too. > > cf: https://www.php-fig.org/psr/psr-7/ > > To the earlier point about existing implementations, while there are a myriad > of older, custom implementations of abstractions around superglobals, there's > only two that are not decade-old proprietary implementations: HttpFoundation > and PSR-7. Those are, realistically, the only implementations that matter. > Anything else would be on the same order of magnitude effort to port to one > of those as to port to this proposal. In a meaningful sense, those are the > only "existing competition". Both also have robust ecosystems that make > leveraging them in an entirely custom app pretty straightforward. > > (Whatever your feelings of the technical merits of either design, that's the > current state-of-the-market.) > > Which therefore begs the question, is this proposal intended to supplant > HttpFoundation and PSR-7, or to become a common underpinning that both of > them wrap, or to be a third cohabitating implementation in the ecosystem? > > It doesn't seem robust enough to supplant both of them entirely, there's > little value to either HttpFoundation or PSR-7 to rewrite their guts to wrap > this object (though it's easier for PSR-7, as an interface, for someone to > write a new implementation of it than for HttpFoundation), which would mean > we'd end up with a 3rd in-the-wild implementation for user space to keep > track of. > > I am unclear how that is a market win.
The win is it allows developer to provide a simple to use object oriented interface *in core*. IOW, without having to bring in an external PHP-code implementation that may or may not break in the future. Another big win would be to allow developers to deprecate use of superglobals in their own apps. However Paul do not want to add an ini setting to disable the use of superglobals. But how could disabling superglobals be done in HttpFoundation or PSR-7? Maybe Paul will reconsider adding such an capability to his RFC because it is something we cannot get with HttpFoundation and PSR-7. Or maybe we should be looking at is a core implementation of PSR-7 instead; one that would allow us to disable access to the superglobals? One that people could subclass, of course. If we did that, we might hash out why some developers do not use PSR-7 and possibly fix its (perceived?) faults in a new PSR to amend PSR-7. -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
