> On 5 Sep 2017, at 03:05, Dan Ackroyd <email@example.com> wrote:
> Stephen Reay wrote:
>> Regarding the big change you suggest, making protected/private methods return false unless a new third parameter is true in is_callable():
>> I think you need to make your intention a *lot* clearer
>> On 29 May 2017 at 12:01, Rowan Collins firstname.lastname@example.org> wrote:
>> Regarding is_callable, ....could lead to some very confusing bugs. IMO, when BC breaks are necessary, they should be big and obvious so people spot and fix them.
> Most of the feedback I got was how modifying the existing is_callable
> function was dumb, so I've updated the RFC, and dropped the idea of
> modifying the existing is_callable function.
> That function will stay as it is, and will be used to determine if a
> variable can be called in the current scope, through either direct
> invocation or call_user_func().
> The RFC instead now proposes a separate function of is_callable_type,
> to determine if a variable can be used as callable in all scopes, and
> so will pass the callable type check for parameters and return types.
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
I appreciate that you've listened to our feedback!
As a userland-only dev I'm not really familiar with the trade offs/gotchas inherent to how parameters are handled in the core. Could you/someone explain/identify why a new function is better than converting the `$syntaxonly` bool parameter into a bitmask of CALLABLE_* constants, which treats Boolean true as CALLABLE_SYNTAXONLY for bc purposes?
Sent from my iPhone