> On Feb 9, 2020, at 8:34 PM, tyson andre <tysonandre...@hotmail.com> wrote:
>
>> 1. Why again are MyClass::methodName() not considered for the non-whitelist
>> vote?
>>
>> Seems to me a developer would be more inclined to implement the expressions
>> that define the class constant's value in a method of the class than in an
>> external function.
>
> My reasons for doing this were to keep the scope small and easy to implement,
> and work on an RFC for methods immediately after if the vote for allowing
> arbitrary functions passed.
>
> The other concern was the edge case `static::method_name()` in class
> constants,
> but `call_user_func(['static', 'method_name'])` or
> `array_map('static::method_name', VALS)`
> causes the same issues.
>
> This leads me to a blocker I've discovered with this implementation calling
> without a whitelist:
> The way PHP resolves the scope is to look for the closest closure or
> user-defined function,
> then to extract the class of that function. (in zend_get_executed_scope).
> I thought the scope would work because `const X = self::Y` works,
> but it turns out ZEND_AST_CLASS_CONST is special cased in AST evaluation.
> My current ideas for fixing this (for class constants and property defaults):
> (Parameter defaults, static variables, and global constants should already
> have reasonable scopes)
>
> 1. Wrap all of the calls the engine is making in a byte copy of
> call_user_func, but with the property `zend_class_entry *scope` set, so that
> zend_get_executed_scope will see that frame's scope and use it instead of the
> caller's scope.
> 2. Add a fake stack frame that acts as if an extra closure (bound to the
> declaring class's scope) was being evaluated.
> 3. Add a brand new function.
>
> If I don't do that, then constant/property evaluation uses the scope of the
> caller, not the class
>
> ```
> class MyClass {
> public static function example() {}
> const X = call_user_func('self::example');
> }
> // this throws in the current implementation
> // due to no active class scope, and that's a bug
> echo MyClass::X;
> ```
>
> If I (or anyone else) can't figure out how to implement the fix, or the fix
> has issues,
> I might remove the secondary vote from the RFC and just vote on the whitelist,
> which excluded functions accepting callables.
> If anyone comes up with a working implementation for a fix (including
> exception handling),
> I'd like to know.
>
Thanks for the reply.
>> 2. Do we really want to add a standard library function 53 characters long?
>>
>> Can we not come up with a more concise name than
>> get_defined_functions_allowed_in_constant_expressions(), like maybe
>> get_const_expr_funcs() or get_const_expressions()?
>
> I was planning to change it if I thought of a better name.
> For get_const_expr_funcs(), I'd think it would be important to be consistent
> about
> naming in the standard library.
> `get_const_expr_functions()` would work, though.
Oh, okay. But don't you think the 'consistent naming in PHP' ship sailed eons
ago?!?
(Sorry, I just could not resist! :-)
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
