Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27458
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.184.236 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=AoH/ubcgoscJYfY21VLdZrYAv0vNFlfJOndvQO5+Ca1o91C4DOWmLo92jLO4TZZ1h3vLSqsS5zpe7g0RTnqjRZV9Rfj98XlEFI86LnyQKJUhJ0loEyLcXp+uvv3Q2VeWBxbm+tP2hMwwVvjF2nr6cpTcgt7/Na6MyHFvH3vZ2DM=
Message-ID: <fe05d1540701151020j3add5a32j3cad81070ca8e6eb@mail.gmail.com>
Date: Mon, 15 Jan 2007 19:20:33 +0100
To: "Sara Golemon" <pollita@php.net>
Cc: internals@lists.php.net
In-Reply-To: <45ABBBCF.8010600@php.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <45ABBBCF.8010600@php.net>
Subject: Re: [PHP-DEV] Runtime JIT Proposals
From: pierre.php@gmail.com (Pierre)

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