Re: Runtime JIT Proposals
| From: | Pierre | Date: | Mon, 15 Jan 2007 12:19:36 +0000 |
| Subject: | Re: Runtime JIT Proposals | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-27454@lists.php.net to get a copy of this message | ||
Hello Sara,
On 1/15/07, Sara Golemon <pollita@php.net> wrote:
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.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
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).
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. --Pierre