Personally, I don't like this. We already have $_REQUEST which can accommodate GET, POST, and COOKIE. I believe it should be up to framework/API authors to implement there own methodologies behind accessing this data. Additional functionality such as setting filters would be a part of that as well.
That said, if you're serious about the idea, a RFC would be helpful in understanding the full extent that you're suggesting. -- Will Fitch On Wednesday, February 22, 2012 at 9:57 AM, Michael Morris wrote: > Before writing up a full RFC I want to put out a feeler on something. > Currently we have several input parameter objects, chief among them > $_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All > of them are arrays and legacy code sometimes writes to them. Locking > them as read only objects would cause a major BC break. > > What if instead we had an Object called $_PARAMETERS which holds the > read only copies of this data. In addition, this would be the first > superglobal object, able to perform some filtering of inputs. Basic > idea.. > > $_PARAMETERS > ->get > ->post > ->cookie > ->headers (The client http headers) > > All of these would be array objects, and all would be read only and > have these methods and properties > > ->filtered: Copy of the array according to the current set filters of > the object. > ->setFilters(): Sets the filters of the input, an array with constant > values for the allowed types. > > And I'll stop there. The basic idea, to add a read only input hive > with some basic object functionality for filtering. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
