> -----Original Message----- > From: mike [mailto:[EMAIL PROTECTED] > Sent: Monday, July 07, 2008 2:09 PM > To: Daniel Brown > Cc: Eric Butera; php-general@lists.php.net > Subject: Re: [PHP] Looking for a reasonable explanation as to why > $_REQUEST exists > > On 7/7/08, Daniel Brown <[EMAIL PROTECTED]> wrote: > > > That's the point --- it's intended as a fallback where you *don't* > > know the method that will be used, or if you want to be lackadaisical > > with your code (which, as we all know, is HIGHLY unrecommended). > > Then you should code for that, not fallback to a lazy overrideable > option. > > if(isset($_GET['foo'])) { $foo = $_GET['foo']; } etc ... > > or > > $foo = array_merge($_GET['foo'], $_POST['foo']) or something like that. > > > Because, in this case, it really doesn't matter if $word is > > obtained via GET or POST, so you can allow external users to use your > > service via an HTTP POST form or a plain URL. > > Then code for it :P I understand the idea, I don't see the need to > create a dedicated construct in PHP for it. Part of PHP's power to me > was finally getting away from the lazy ASP (VB-based) > Request.Value('foo') or whatever it was and not able to identify if it > was post, get, etc and making the coder define exactly what source of > data he's getting it from.
*cough* ... Request.Value? That seems like lazy VB.NET/ASP.NET code to me. :) It can be split into either Request.QueryString (for GET) or Request.Form (for POST). Anyway, a bit OT... Todd Boyd Web Programmer
