Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27454
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.184.238 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=QnVtt6J9QajTDAVll+TFcEfJm76KAIIhnmg27k4B8nN7dRxgvVQ1PbAwesqj8TYAsW7mgj2mR57O/Z1UextJZwO9iZtg4ZUKqBZhO7dBVQR0xGZJisQJJjkllTmBjZtCTKWRkllBEekpv4DrmT4qudo+KWQz+KULg6MQwAdmMZI=
Message-ID: <fe05d1540701150419i70f2662cg413857375ec829c4@mail.gmail.com>
Date: Mon, 15 Jan 2007 13:19:36 +0100
To: "Sara Golemon" <pollita@php.net>
Cc: internals@lists.php.net
In-Reply-To: <45AB0207.5080505@php.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <45AB0207.5080505@php.net>
Subject: Re: [PHP-DEV] Runtime JIT Proposals
From: pierre.php@gmail.com (Pierre)

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