On 1/27/07, Sara Golemon <[EMAIL PROTECTED]> wrote:
> 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.
That's not what I had in mind while talking about an object. ArrayAccess was never an option for the exact reasons you quoted in the cons. However if this problem can get fixed at the engine level, why not. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
