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.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
