For reasons best left on IRC, it looks like I'll be working on runtime
JIT. To that end, I've come up with a few proposals of varying
complexity and feature-set completeness:
Option 1:
Dump support for compile-time JIT and replace it with a call at runtime
using the same semantics.
Advantages: No change in the API (well, no further change anyway,
Unicode support pretty much guarantees that things will change regardless).
Disadvantages: Could someone be relying on compile-time JIT for
something already? Maybe activation triggers an action which has to
take place prior to script execution? For what I've seen JIT isn't in
heavy use, but my perceptions on the topic aren't definitive.
Option 2:
Leave compile-time JIT alone, and add a second callback for runtime JIT.
Advantages: Doesn't break BC, and offers extensions the chance to know
that the code contains autoglobal references without actually having to
act on them unless they're needed.
Disadvantages: Adds to complexity/confusion by having two separate
callbacks for essentially the same action.
Option 3:
Extend JIT signature with a "stage" parameter to indicate if the JIT
trigger is occuring during compile-time or run-time. The callback can
decide when/if it performs processing using current return value
disarming semantics.
Option 4:
Include fetchtype and subelement during runtime JIT callback allowing
JIT callback to only do work necessary to prepare for the read/write
call being performed.
e.g.
int php_example_jit_callback(int str_type, zstr str, int str_len,
int stage, zval *container, int fetch_type, zval *element);
Where str_type/str/str_len indicate the name of the variable being
JITed, stage is one of COMPILETIME or RUNTIME, container is the
autoglobal itself.
Fetch_type is ZEND_FETCH_(DIM_|OBJ_)?_(R|W|RW), and element is the
specific property/offset (only applicable for DIM/OBJ fetches, NULL for
plain fetch.
Advantages: Gives maximum flexibility to the implementation. In the
case of http request encoding, it allows the decoder to differentiate
between requests for a single element and fetches which want to retreive
the entire array (e.g. foreach).
Disadvantages: Adds a lot of complexity to the fetching of autoglobals
and qand effectively doubles the amount of callback work being done for
autoglobal objects. Will also confuse implementers on what the
difference between this fetch callback is and the
(read|write)_(dimension|property) callbacks used by objects.
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:
$postdata = $_REQUEST;
foreach($postdata as $idx => $val) {
$postdata[$idx] = some_filter_func($val);
}
Were $_REQUEST turned into an object with overloaded array access, these
changes to $postdata would modify the values in the original $_REQUEST
(due to the reference-like behavior of PHP5+ objects).
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.
If I can get something approaching a semi-consensus on direction, I can
have an implementation (or a couple, depending on feelings on the
matter) in a few days.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
