Re: Runtime JIT Proposals

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