Hi again, guilhermebla...@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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
