Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:93661 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 91577 invoked from network); 31 May 2016 20:14:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 May 2016 20:14:00 -0000 Authentication-Results: pb1.pair.com smtp.mail=dev@mabe.berlin; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=dev@mabe.berlin; sender-id=unknown Received-SPF: error (pb1.pair.com: domain mabe.berlin from 80.237.132.167 cause and error) X-PHP-List-Original-Sender: dev@mabe.berlin X-Host-Fingerprint: 80.237.132.167 wp160.webpack.hosteurope.de Received: from [80.237.132.167] ([80.237.132.167:37056] helo=wp160.webpack.hosteurope.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CB/10-25096-680FD475 for ; Tue, 31 May 2016 16:13:59 -0400 Received: from dslb-178-008-020-062.178.008.pools.vodafone-ip.de ([178.8.20.62] helo=[192.168.178.53]); authenticated by wp160.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1b7q31-0006H5-AH; Tue, 31 May 2016 22:13:55 +0200 To: Nikita Popov References: <40598408-3d6a-005b-e73d-ac464b643112@mabe.berlin> Cc: PHP Internals Message-ID: <268c8e2b-dc73-5fbf-e71f-a951941bee4d@mabe.berlin> Date: Tue, 31 May 2016 22:13:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E89A034661E5D2FA2607363C" X-bounce-key: webpack.hosteurope.de;dev@mabe.berlin;1464725639;03551488; Subject: Re: [PHP-DEV] Bug or expected behavior? From: dev@mabe.berlin (Marc Bennewitz) --------------E89A034661E5D2FA2607363C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 05/31/2016 09:59 PM, Nikita Popov wrote: > On Tue, May 31, 2016 at 9:54 PM, Marc Bennewitz > wrote: > > Hi, > > today I was running into an issue with a function lookup over > namespace. > > https://3v4l.org/qF7cK fails > https://3v4l.org/evVic works > > For me it looks like the function lookup for "is_null" in this > case gets cached on first use > and on second call no check will be done if this function exists > in the current namespace > before looking in the root namespace. > > Because PHP is a dynamic language this behavior looks wrong > (unexpected) to me > and also HHVM does handle it as I would expect it. > > Thanks, > Marc > > > This is a known issue: https://bugs.php.net/bug.php?id=64346 Much thanks Nikita for the link. Didn't found it myself. But this bug ticket doesn't look nice - No comments since 2¹/² years. Is a suggestion from someone without enough knowledge of the engine / opcache. Wouldn't it be better to move this performance feature into opcache and make it configurable over "opcache.optimization_level "? > > Regards, > Nikita Thanks, Marc --------------E89A034661E5D2FA2607363C--