On Wednesday, February 22, 2012 at 10:10 AM, Michael Morris wrote: > $_REQUEST does nothing of the sort, and it's use is dangerous in > RESTful architecture. $_REQUEST is a smash together of $_GET, $_POST > and $_COOKIE, in that order but the php.ini directive can change it. > Hence there's no way of knowing if $_REQUEST['password'] came from > $_COOKIE, $_POST, or $_GET, and worse, if two values in those source > arrays have the same key $_REQUEST will overwrite them. $_REQUEST to > be honest, is a lame shortcut and bad idea almost on par with > register_globals. > >
$_REQUEST isn't dangerous - the programmer using it is. > > I'm not recommending $_REQUEST. > > $_PARAMETERS is an object, not an array. I suppose if treated like an > array it could behave like request - but I deeply dislike that idea > because it is a repeat of the mistake of $_REQUEST. > > You're going to have a hard time selling this. Adding an object to global scope by adding yet another super global is a mess. You'd have a much easier time selling a SPL class which handles this functionality. Or, even better, write this *in* PHP. There wouldn't be a substantial performance improvement, and you wouldn't be forcing ideologies on other developers. If you're wondering what I mean by this, your suggestion of "setFilters" would require an interface that defines the behavior intended for filtering content. On top of this, you'd need to add getFilters, getFilter, removeFilters, removeFilter and addFilter to name a few. All of this can (and should IMO) be done within PHP. > > To get a value from a get request I'd use $_PARAMETERS->get['myVar']; > To get it's filtered value I'd use $_PARAMETERS->get->filtered['myVar'] > To set those filters I'd use $_PARAMETERS->get->setFilters( $filters ); > > As I said before, you should add a RFC entry if you want this taken seriously. The information you provided is just not enough. > > > > On Wed, Feb 22, 2012 at 10:03 AM, Will Fitch <will.fi...@gmail.com > (mailto:will.fi...@gmail.com)> wrote: > > 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 > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
