Support execution scope realization at runtime (or last pieces for private class support)

9 years ago by guilhermeblanco@gmail.com — view source

unread

Hi internals!

I want to revive an old patch I was working on last year, and open for
discussion the last missing piece to make it fully complete, allowing me to
write a RFC.

Link to patch introducing support to private classes:
https://github.com/php/php-src/pull/947

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... =(

I wonder what would be necessary to make this patch possible, if there's
any interest to move this forward and potentially target it for 7.1 release.

Regards,

--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

9 years ago by Leigh — view source

unread

On 29 October 2015 at 02:57, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:

I wonder what would be necessary to make this patch possible, if there's
any interest to move this forward and potentially target it for 7.1
release.

I'm still interested in this, and willing to help out with implementation
if required.

9 years ago by Andrea Faulds — view source

unread

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/

9 years ago by guilhermeblanco@gmail.com — view source

unread

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,

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/

--

--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

9 years ago by Andrea Faulds — view source

unread

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/