Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:89009 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 24966 invoked from network); 29 Oct 2015 19:12:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Oct 2015 19:12:52 -0000 X-Host-Fingerprint: 176.25.179.123 unknown Received: from [176.25.179.123] ([176.25.179.123:28616] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DB/A1-16245-3BF62365 for ; Thu, 29 Oct 2015 14:12:52 -0500 Message-ID: To: internals@lists.php.net References: Date: Thu, 29 Oct 2015 19:12:38 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:41.0) Gecko/20100101 Firefox/41.0 SeaMonkey/2.38 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 176.25.179.123 Subject: Re: [PHP-DEV] Re: Support execution scope realization at runtime (orlast pieces forprivate class support) From: ajf@ajf.me (Andrea Faulds) Hi again, guilhermeblanco@gmail.com wrote: > I'm very happy to see you back! You're a great contributor to PHP... =) Oh, er, thank you. > Sorry, I may have written in a bad form, but here is the context... I think I might have just been too hasty to guess what you wanted it for. > Looking at this phpt file > https://github.com/guilhermeblanco/php-src/blob/class-modifiers/Zend/tests/visibility_modifiers/namespaced_private_class_different_namespace_instantiation.phpt > It currently fails giving this error: "Fatal error: Top level scope cannot > instantiate package private class A\B in %s on line %d" > What happens is that at runtime, there is no scope definition defined when > I look for EG(scope) in the zend_vm. This means that it doesn't matter if > the code is in a top-level or inside of a namespace (but not inside of a > class/method/function), scope is always null. > This breaks the execution, because it can't correlate to the proper > namespace it's instantiating and the entire approach of restricting usage > of private classes doesn't work. > Does that make sense now? I actually detailed in all the written tests > which ones currently fail, all because of exact same situation. > > My question falls back to anyone with deeper knowledge of zend_vm or > internals how and what would be necessary to finalize the patch (this is > the last missing piece as it currently stands), so I could officially > propose for discussion by everyone here. Ah, I see. That's a different use-case from what I was thinking about, and now I see why the patch makes sense. Thanks for filling me in. :) -- Andrea Faulds http://ajf.me/