Autoglobal CVs without silence -- Summary View as Markdown

Btw, for people who truly need the Unicode support I actually do think we might want to consider requiring them to fetch the input
variables through a new API and/or object. I don't think we need to make it seamless if the "default" behavior we provide (whatever
that ends up being) isn't good enough...

Andi

-----Original Message-----
From: Andi Gutmans [mailto:andi@zend.com]
Sent: Saturday, January 27, 2007 9:15 AM
To: 'Sara Golemon'; 'internals@lists.php.net'; 'Andrei
Zmievski'; 'Dmitry Stogov'
Subject: RE: [PHP-DEV] Autoglobal CVs without silence -- Summary

Hi Sara,
I don't feel to great with this patch. It kind of feels like
twisting the language implementation around for some very
specific problem which probably shouldn't be fixed at this
level. Andrei says performance of Unicode isn't great so it
shouldn't matter too much, but I think a) it's not only about
performance but also about maintainability. The code in PHP 6
is already much more complex than that of PHP 5 and has
become much harder to maintain. Such additional changes will
make it worse b) There will still be plenty of people who use
PHP 6 in PHP 5 mode.

I still haven't quite understood why not just do the
detection on the whole auto-global when it's being fetched
(or even during request startup). As Andrei said, it's slow
anyway so for people who need Unicode that should be an
affordable hit.

Maybe I don't understand the problem in enough detail and it
might make sense for me to talk to Andrei via voice directly,
but I really don't think we should be over eager commiting
this patch. It'll not be good for the engine long term (not
that I don't appreciate your efforts and hard work on this patch).

Andi

-----Original Message-----
From: Sara Golemon [mailto:pollita@php.net]
Sent: Tuesday, January 23, 2007 11:02 AM
To: internals@lists.php.net; Andrei Zmievski; Andi Gutmans; Dmitry
Stogov
Subject: [PHP-DEV] Autoglobal CVs without silence -- Summary

OK. Now your patch will work, but I would like to >>
think about
more elegant solution.
The problem that I am busy with other work.
Could you please wait a week and then commit it if >> I won't
return (on the next Tuesday).

Argh. Can we please accelerate this somehow?
This patch is necessary for the HTTP request > decoding work in
PHP 6 and we really should > get it done sooner than later.

Okay, rewind and reset time.

Dmitry, here's a quick summary of what's being done, how, and why.

Initial Problem: PHP6 needs better http input encoding detection,
preferably with minimal wasted effort in conversion and limited
vectors for conversion failure based attacks.

Proposed Solution: Wait until the first time a given input
argument is
requested before actually converting it. This allows scripts to
perform their own (potentially more
relevant) determination of what the correct input encoding is.

Proposed Implementation for this solution: Make JIT be
runtime based
and fine-grained enough to signal not just the autoglobal being
fetched, but what specific dimension/property within that
auto global
is being requested. Using runtime-dimension-JIT to decode input
arguments as they are requested.

Rejected Implementation: Use object/array-access overloading to JIT
the values instead. While this solution is the simplest and can be
done with relatively few LOCs, it breaks assumptions about the GPC
auto globals (is_array() fails,
is_object() succeeds, assignments of the autoglobals becomes
"reference-like"*). In short, this solution introduces BC issues.

---

Next Problem: How to actually make runtime-JIT with dim/prop level
granularity?

Proposed Solution: Catch fetches during FETCH_DIM/FETCH_OBJ
execution
handlers.

---

Next Problem: auto_globals aren't processed as CVs, meaning that
during FETCH_DIM, there's no way to tell if op1 came from an auto
global or not (since the fetch happened earlier).

Solution (Implemented last week): Remove restriction on CVing auto
globals by adding a fetch_type field to auto global structure.

---

Next Problem: Silence operator forces non-CV even in
situations where
a CV is appropriate since the associated fetch_dim/obj op would not
fall outside of silence scoping.

Proposed Solution (patch from prior email): modify the variable
parsing routines slightly to rewrite simple fetch ops to CV'd
fetch_dim/obj ops when appropriate.

---

I'm not meaning to apply pressure (a week doesn't effect my
timetable
any), I can even move-forward with the next (and
last) ZE related patch (FETCH_DIM/FETCH_OBJ handling) separate from
this one. I'm just trying to balance Andrei's timetable on
one side,
with a desired to not overwhelm you and Andi with ZE patches on the
other. Hopefully this summary helps everyone get on the same page.

-Sara

• • Sidenote: I refuse to call object behavior "reference
    by default",
    I've had too many people notice that it's not actually true
    and expect
    me to explain why in 2 minutes without the aid of a whiteboard.in

--
To
unsubscribe,
visit: http://www.php.net/unsub.php