As I told you, there was already a consensus on this solution, check
my initial proposal (solution #2):
http://news.php.net/php.internals/26965
No, that's a consensus on compile-time versus runtime. What I offered
in my post was four variants of how runtime could be implemented.
In response to the suggestion to just turn $_REQUEST (et.al.) into
objects with overloaded array access, the big danger there is that the
following behavior would change:
It will bring a BC break as well or is_array($arrayaccessobject) will
have to return true and we have to be sure about its implementation
(like properties access not always working well).
Right, we all agree that approach won't work.
Personally, I like Option 4, but then I like complexity. I can
certainly see going for any of the others, but I want to go with
something that the rest of the group can see being appropriately useful.
I like my initial proposal. All it needs is an extra function and to
move the JIT management to runtime. The complexity is the same as what
we have now.
What if I want to inspect one particular element for encoding hints?
/* Initially set encoding to ascii just for parsing 'ei' */
http_input_encoding('ascii');
if (!empty($_REQUEST['ei'])) {
/* Request identified itself */
if (!http_input_encoding($_REQUEST['ei'])) {
handle_bad_input_encoding();
}
} else {
/* Fallback on best-guess */
http_input_encoding_detect('UTF-8,ISO-8859-1');
}
/* Work with the rest of $_REQUEST using the identified encoding */
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
