Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:24442
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Mon, 17 Jul 2006 23:33:48 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <697792544.20060717233348@marcus-boerger.de>
To: Sara Golemon <pollita@php.net>
Cc: Jeff Moore <jeff@procata.com>, internals@lists.php.net
In-Reply-To: <000001c6a9af$5d73d100$8f051fac@vait>
References: <347185750.20060715202622@marcus-boerger.de> <002c01c6a888$19b133e0$8f051fac@vait> <3228902ffeb3f76f56afad7e58490abd@procata.com> <000001c6a9af$5d73d100$8f051fac@vait>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Long awaited line directive
From: helly@php.net (Marcus Boerger)

Hello Sara,

Monday, July 17, 2006, 7:09:30 AM, you wrote:

>>> One minor thought I'd offer up is an option INI setting to disable 
>>> creation of the opcode.  This allows the #line directives to be used in 
>>> dev/debug environments without causing an impact for production servers 
>>> during execution.  It's not a major performance hit, but it's something.
>>>
>> Why not leave it up to the user land code generator to include the 
>> directive in the debug version or generate without it in the production 
>> version?
>>
> Indeed.  This suggestion was cross-wired with another thought when an 
> enable/disable switch made more sense.  For the sake of code-generators it 
> does make more sense to simply not generate the line during pre-compile.

That is actually the preferred solution. An additional opcode does not
have any impact on the runtime. So having the ocode linger around doesn't
do anything. Which is the same for regenerating the code without #line
directives. On the contray adding a new ini setting affects every request
so i guess the answer is quite obvious.


Best regards,
 Marcus