> Btw, having a request object was one of the #1 requests in framework
:) People actually really like encapsulating this because it
> also makes unit testing easier down the road...
> Just mentioning this because I don't think we should be too set with
our ways esp. for people who need to accomplish more
> functionality.
>
For the record, I *do* prefer the simplicity of implementation of going
with a request object, and I *personally* don't see it as a
show-stopping BC break. Then again, I didn't see that fgets() change as
show-stopping either.
So let's start back from square one. How about a fresh round of
discussion on the request object approach, in psuedo-code:
class PHPGetObject implements ArrayAccess
{
private $decoded = array();
public function __offset_get($varname)
{
if (!isset($this->decoded[$varname])) {
$val = http_decode_get($varname);
$this->decoded[$varname] = $val;
}
return $this->decoded[$varname];
}
/* plus set,isset,unset of course */
/* Probably need an iterator too */
}
Pros: Fast, (mostly) clean, and cheap.
Cons: Breaks the following BC bahaviors:
* is_array($_GET) === false
* is_object($_GET) === true
* Referenceishness:
$get = $_GET;
$get['foo'] = 'bar';
var_dump($_GET['foo']); /* 'bar' */
My vote: +1 as I don't think the Cons are that serious.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
