Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108433
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <DM5PR07MB3067CC4C8C4C803367091325F91E0@DM5PR07MB3067.namprd07.prod.outlook.com>
Date: Sun, 9 Feb 2020 23:10:00 -0500
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <091D966F-13B4-4E49-B882-80D852AD795A@newclarity.net>
References: <DM5PR07MB30676BB61C723F999C6C4B40F91E0@DM5PR07MB3067.namprd07.prod.outlook.com>
 <9C0A5E79-6925-43B4-84C6-A2DA007A9F1A@newclarity.net>
 <DM5PR07MB3067CC4C8C4C803367091325F91E0@DM5PR07MB3067.namprd07.prod.outlook.com>
To: tyson andre <tysonandre775@hotmail.com>
Subject: Re: [PHP-DEV] [RFC] Allow calls to global functions in constant
 expressions
From: mike@newclarity.net (Mike Schinkel)

> On Feb 9, 2020, at 8:34 PM, tyson andre <tysonandre775@hotmail.com> =
wrote:
>=20
>> 1. Why again are MyClass::methodName() not considered for the =
non-whitelist vote?=20
>>=20
>> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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 =3D 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)
>=20
> 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.
>=20
> If I don't do that, then constant/property evaluation uses the scope =
of the caller, not the class
>=20
> ```
> class MyClass {
>    public static function example() {}
>    const X =3D 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;=20
> ```
>=20
> 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.
>=20

Thanks for the reply.

>> 2. Do we really want to add a standard library function 53 characters =
long?=20
>>=20
>> 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()?
>=20
> 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