# Runtime JIT Proposals

- Thread: https://externals.io/message/27456
- Original archive: https://news-web.php.net/php.internals/27456
- Started by Sara Golemon on 2007-01-15T17:37:19+00:00
- Messages: 2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #27456 — Sara Golemon — 2007-01-15T17:37:19+00:00

URL: https://externals.io/message/27456#27456

> 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.

> > […]
> 
> 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.

> > […]
> 
> 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

---

## #27458 — Pierre — 2007-01-15T18:20:33+00:00

URL: https://externals.io/message/27456#27458 · In reply to: #27456

Hello,


> > […]
> 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).

> > […]
> Right, we all agree that approach won't work.
>
> > […]
> 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