Hello,
On 1/15/07, Sara Golemon <pollita@php.net> wrote:
> > 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.
The consensus was on #2 (which is your #1).
> >> 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'])) {
it is typo right? like using a function http_input_encoding_detect_from(...)?
> 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 */
Sorry but that's horrible :)
That's way too complex to handle the input enconding. PHP Unicode
functions can include some magic function to detect the encoding of a
given string but I hardly see it as a specific http function.
The two functions needed can be:
http_input_encoding: set the input encoding (UTF-8, ASCII, etc.)
http_input_encoding_error: get the error (invalid sequence, badly formed,etc.)
If we like to go with #4, I rather prefer a more drastic change and go
with something like perl/python CGI objects. And it is a piece of cake
to implement in ext/filter. #4 makes possible as well to implement #1
to minimize the impact on the existing applications (relying on GPC).
--Pierre
