Hi Sara, Sorry but I wasn't on IRC so I don't quite understand what you're trying to accomplish ;) Can you please explain? Once I understand what you're trying to accomplish I'll be more than happy to provide feedback to the options list.
Thanks, Andi > -----Original Message----- > From: Sara Golemon [mailto:[EMAIL PROTECTED] > Sent: Sunday, January 14, 2007 8:25 PM > To: internals@lists.php.net > Subject: [PHP-DEV] Runtime JIT Proposals > > 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
