Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:70483 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 42669 invoked from network); 3 Dec 2013 09:14:17 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Dec 2013 09:14:17 -0000 Authentication-Results: pb1.pair.com header.from=ellison.terry@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ellison.terry@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.181 as permitted sender) X-PHP-List-Original-Sender: ellison.terry@gmail.com X-Host-Fingerprint: 74.125.82.181 mail-we0-f181.google.com Received: from [74.125.82.181] ([74.125.82.181:60299] helo=mail-we0-f181.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 95/B1-34518-9E0AD925 for ; Tue, 03 Dec 2013 04:14:17 -0500 Received: by mail-we0-f181.google.com with SMTP id x55so12819707wes.26 for ; Tue, 03 Dec 2013 01:14:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=d7QnkV3bIUb+9H4y2cgPsofjRwzgcNubEmK+k2tKFDE=; b=Jg2USfwoFyXfuPyuGiXbUKUqpWVh5VMGkR/4l1wRS6KxJCpQw0UU16ZMeDKg3+mogE vMdHkmiCAQbr2jARTEoCTTZIYTQtuNlgSSNPmF742y/jdqbkRxTTWqwUlGLMVG9mWYYA SF00Lp/QPNFLFjhjqgVgC3E6D3PDNAXc3kGDjZDR9l4R9PE9dCe5RXUTjZaP7MhE/Szt SxVYLQv1AmBZrpqv/Z5bKlmBeDu+9Tnu6Gp8vWfCFR9/3TNZJaR2eqlHb4byH4WmMZBz xMpN5jd//uCLKieMLV5mQCvt0z7t5G/jwuQjKX2+ukTJkycHiweNp0rk0xGgdXqu+fQ2 /IGA== X-Received: by 10.194.80.137 with SMTP id r9mr1214501wjx.88.1386062053828; Tue, 03 Dec 2013 01:14:13 -0800 (PST) Received: from [192.168.0.15] (97e69817.skybroadband.com. [151.230.152.23]) by mx.google.com with ESMTPSA id nb16sm3609484wic.0.2013.12.03.01.14.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 01:14:13 -0800 (PST) Message-ID: <529DA0E4.30302@gmail.com> Date: Tue, 03 Dec 2013 09:14:12 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Stas Malyshev , PHP Internals References: <528CE64A.1020303@gmail.com> <528EA006.2090400@gmail.com> <52993190.4010905@gmail.com> <52995F97.7000901@sugarcrm.com> <5299B124.3030809@gmail.com> <529A5947.5060701@sugarcrm.com> <529A831C.80401@gmail.com> <529D9564.4070909@sugarcrm.com> In-Reply-To: <529D9564.4070909@sugarcrm.com> Content-Type: multipart/alternative; boundary="------------000101010101090907080608" Subject: Re: [PHP-DEV] Comments on non-unique naming convention for closures From: ellison.terry@gmail.com (Terry Ellison) --------------000101010101090907080608 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Stas, > I understand why you proposed content-based hash. What I was > suggesting is not replacing it but amending it to produce different > hash even in case same code would be encountered in different places - > e.g. by hashing not only the text but also filename & line number (or > counter). I'm not sure if it is strictly necessary for OPcache (could > be that it is not) but in general having multiple functions with the > same name floating around is not a very good idea, IMO, if we can > avoid it... After all, that's how we got this problem from the start :) Yup, the scheme (in PHP speak): $mangled_name=sprintf("\0{closure}%s-%u-%x", $filename, $offset_into_file, $hash); addresses the concerns that you voice. I can't think of use cases where this would lead to false collisions. I will code up my patch on this basis. Thanks Terry --------------000101010101090907080608--