Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59918
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <19.18.35770.7A9788F4@pb1.pair.com>
References: <CAGa2bXZ6G=Cphjrde3u1Mq3AAw-4yJk3s28vNe+Aybt2nGTumg@mail.gmail.com>
 <CAKOpQSzN4xkJLL_JwbXx1iOJs6Hnxnjh+D2qUjpShqgW8N2S6g@mail.gmail.com>
 <CAGa2bXaG_SR-F2eKUu3=Quzm6scOhOGB5d4gwZAmCBZTwB=q=w@mail.gmail.com>
 <CAGa2bXbyhUGMSZsiP6hSap4fi0pVA8sKVeps4ScPb9QQWidkTg@mail.gmail.com>
 <4F862AAC.90003@lerdorf.com> <4F86761A.9010801@lsces.co.uk>
 <CAGa2bXZRuYWBeWRNkF5rbL1Drtt8uP2VeL4mCoXdxw8iswwEVQ@mail.gmail.com>
 <CAL0xaBFkzgLqnyTpJXqWbvnYNHakV+K5L173tO-a==HiGSXUtw@mail.gmail.com>
 <4F876E36.1020400@gmail.com> <CAGa2bXZsaae=xYPDSMc0yV_O6G3=tKjV5pV=RuxiMrWra=Oy1Q@mail.gmail.com>
 <4F87799D.4060601@sugarcrm.com> <CAGa2bXbeGjFPaw1=H7anSerAVCOkgY=8iuHcATGB93tuTz_Y9Q@mail.gmail.com>
 <CAGa2bXacWzafy84_yK=QAmspiZd6Yo+KNKWpywjgLxvqpo32zg@mail.gmail.com>
 <4274B530-5FB8-4292-9262-37044CF98B8B@punkave.com> <4F87B1D6.2070008@sugarcrm.com>
 <4F87B81F.9000603@gmail.com> <03.6A.35770.215388F4@pb1.pair.com>
 <CAORXhG+LF7tqRaSZHJyrFNiezg1pnkeRKqeDSvRLM0cbn9=fUQ@mail.gmail.com> <19.18.35770.7A9788F4@pb1.pair.com>
Date: Sat, 14 Apr 2012 07:45:45 +0900
Message-ID: <CAGa2bXbgFHXC0ng-YZqh7sTsWWjmCTo0SOHLrpUcWp4fUAdyWA@mail.gmail.com>
To: "Matthew Weier O'Phinney" <weierophinney@php.net>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi,

2012/4/14 Matthew Weier O'Phinney <weierophinney@php.net>:
> On 2012-04-13, Tom Boutell <tom@punkave.com> wrote:
>> Wouldn't this be a significant performance hit when multiplied by
>> every class file in a project?
>
> Typically, you'd cache the end-result of pre-processing, so that
> subsequent requests can use the processed results. In other words, you
> incur the expense once per file.
>

We don't have to look up already processed for
script_once() by ourselves. Looking up included file
cache array is enough. script_once() would be fast
enough for most cases. script() will be slower, but
nobody would care.

Regards,

--
Yasuo Ohgaki

>> On Fri, Apr 13, 2012 at 10:15 AM, Matthew Weier O'Phinney
>> <weierophinney@php.net> wrote:
>> > On 2012-04-13, David Muir <davidkmuir@gmail.com> wrote:
>> > > On 13/04/12 14:55, Stas Malyshev wrote:
>> > > > > If this is a pecl module library developers cannot use it and tr=
ust
>> > > > > that on php 5.n, it just works. That would fork the language in =
an
>> > > > > undesirable way. It should be a core feature, no ini flag, no
>> > > > > sometimes-there module.
>> > > > PHP 5.n is at least a year away, wide adoption of it - more like 5=
 years
>> > > > away. So if you want to write code that would run anywhere (as opp=
osed
>> > > > on systems you control) you'd have to wait minimum 5 years. Wouldn=
't it
>> > > > better to have it earlier?
>> > > > OTOH, requiring extensions is a common thing for applications, and=
 any
>> > > > pecl extension is one command away for most setups, or one downloa=
d away
>> > > > for others. And can be made work even in 5.2 if desired.
>> > >
>> > > Can't it also be handled using streams to inject a leading <?php to =
the
>> > > file prior to inclusion? A PECL extension would then just make it ru=
n a
>> > > bit faster.
>> >
>> > I made this very suggestion earlier this week (we do this in ZF1 to
>> > emulate short tag support for those who use them).
>
>
> --
> Matthew Weier O'Phinney
> Project Lead =A0 =A0 =A0 =A0 =A0 =A0| matthew@zend.com
> Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>