Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:89007 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22216 invoked from network); 29 Oct 2015 18:58:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Oct 2015 18:58:03 -0000 Authentication-Results: pb1.pair.com header.from=guilhermeblanco@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=guilhermeblanco@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.169 as permitted sender) X-PHP-List-Original-Sender: guilhermeblanco@gmail.com X-Host-Fingerprint: 209.85.214.169 mail-ob0-f169.google.com Received: from [209.85.214.169] ([209.85.214.169:35180] helo=mail-ob0-f169.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 27/21-16245-83C62365 for ; Thu, 29 Oct 2015 13:58:01 -0500 Received: by obctp1 with SMTP id tp1so25283238obc.2 for ; Thu, 29 Oct 2015 11:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=b2hDVPwC6swC05G8eQ012YbqTU77diP7gggXV2saq+o=; b=vpIJLaL8Uo5B+f7YJFSGa2q2/Ax+REufZwhuCr0Yh/7RsPHQBDpOqVoGPRCXIg40m5 3shdsna84t/JCopKOEPQ5LHcpgD5zTnHIM1m4BnnGu3fwehQ/ypOb0wfDoJBQQdy6EM9 VFN4US9Y6CBKF48SJtnsrAzBDN2YI/fgT/v6dHgAZ+AjPkH2G4ahI6APAB+EYGrWEy5B C5IyuLW5S4qdTf85pHByJ8qa0HmMdayYcSMmW+9VzNDN3/xQWhFzUCFSLX2CXUJpV+GK ttUOMBpJIq0sKjij0Uw25JgLBmskyqx3dRyzileQ9WEvgxaHqacMogfv94YsSiE0opDv R6nw== X-Received: by 10.60.76.42 with SMTP id h10mr2509532oew.13.1446145077556; Thu, 29 Oct 2015 11:57:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.206.3 with HTTP; Thu, 29 Oct 2015 11:57:38 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Oct 2015 14:57:38 -0400 Message-ID: To: Andrea Faulds Cc: PHP internals Content-Type: multipart/alternative; boundary=047d7b33d906a43de5052342e36c Subject: Re: [PHP-DEV] Re: Support execution scope realization at runtime (or last pieces forprivate class support) From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com") --047d7b33d906a43de5052342e36c Content-Type: text/plain; charset=UTF-8 Hi Andrea, I'm very happy to see you back! You're a great contributor to PHP... =) Sorry, I may have written in a bad form, but here is the context... 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. Regards, On Thu, Oct 29, 2015 at 2:41 PM, Andrea Faulds wrote: > Hi Guilherme, > > guilhermeblanco@gmail.com wrote: > > Currently, there's no way to determine at runtime what is the scope of the >> execution. This means you can't resolve if the current instruction is >> happening on a top-level scope, in a class definition, namespace, function >> or method. >> >> Together with this (maybe even more importantly), there's no way to >> resolve >> namespaces in any way, since they only exist up to compile time (they >> become part of class name through string append), and no real data >> structure around it exists. I was forced to create a weird string check to >> make it work... =( >> > > Making plain string literals in function calls be interpreted differently > depending on context does not sound like a good idea to me. Functions > shouldn't rely on hidden (non-syntactically-obvious) contextual > information; I think func_get_args() et al. were a mistake. > > I'm not sure why we'd need to resolve namespaces at runtime anyway. If you > just need to pass the name of a class to a function, we have ::class. Is > there some use-case I'm unaware of? > > Thanks. > > -- > Andrea Faulds > http://ajf.me/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Guilherme Blanco MSN: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada --047d7b33d906a43de5052342e36c--