Everything

php

[RFC] Add Directive to Make All Namespaced Function Calls Global

php.internals

Nick Lockheart

2 years ago

Good morning all:

When calling functions from the *global* namespace, the PHP parser
creates opcodes that use those functions directly. When those functions
are certain built-in functions, the parser can use special opcodes that
are optimized for those function calls.

When calling functions from *within* a namespace, the parser does not
know at compile time if the function is defined in the current
namespace or if the global function will be used.

Because unqualified function calls are ambiguous, the parser adds an NS
Lookup opcode which performs a runtime check for the function name in
the current namespace, and then falls back to the global namespace if
the function is not defined locally.

This also prevents the parser from using dedicated opcodes for built-in
functions.

This incurs a performance penalty.

In the past, RFCs that aimed to address this issue got too hung up on a
syntax discussion, rather than a simple “should we solve this” question
proposed to the community.

I would like to discuss and then vote on this proposal as a feature,
without getting into any specifics of syntax.

I propose that we vote yes/no on if there should be some way, whatever
that way ends up being, to tell the parser to always treat unqualified
function names as global.

I think it's important to get a “clean vote” on this issue, to separate
out if past objections were objections to the concept, or if only the
syntax proposed in past discussions was disfavored.

To that end, I have created the following RFC:

https://wiki.php.net/rfc/global_function_parser_directive
I am asking that we discuss and vote on the following question:

“Should there be some way for developers to signal to the parser at
compile time that all unqualified function names found in a namespace
context are global, without a namespace lookup?”

Yes: We should do this, let's discuss syntax possibilities.

No: This should not be a feature at all.

Thank you for your consideration.

Christoph Becker

2 years ago

On 04.08.2024 at 15:09, Nick Lockheart wrote:

> To that end, I have created the following RFC:
>
> https://wiki.php.net/rfc/global_function_parser_directive
> I am asking that we discuss and vote on the following question:
>
> “Should there be some way for developers to signal to the parser at
> compile time that all unqualified function names found in a namespace
> context are global, without a namespace lookup?”
>
> Yes: We should do this, let's discuss syntax possibilities.
>
> No: This should not be a feature at all.

Thanks for the PR!

However, it seems to me that the "syntax possibilites" are an important
part of the vote.  Maybe all will agree that having that option is good,
but there still might not even be consensus on the "syntax".

Maybe just some straw poll to gauge interest in the general feature
would be more appropriate?

Christoph

Nick Lockheart

2 years ago

On Sun, 2024-08-04 at 20:02 +0200, Christoph M. Becker wrote:

> On 04.08.2024 at 15:09, Nick Lockheart wrote:
>
> > To that end, I have created the following RFC:
> >
> > https://wiki.php.net/rfc/global_function_parser_directive
> > I am asking that we discuss and vote on the following question:
> >
> > “Should there be some way for developers to signal to the parser at
> > compile time that all unqualified function names found in a
> > namespace
> > context are global, without a namespace lookup?”
> >
> > Yes: We should do this, let's discuss syntax possibilities.
> >
> > No: This should not be a feature at all.
>
> Thanks for the PR!
>
> However, it seems to me that the "syntax possibilites" are an
> important
> part of the vote.  Maybe all will agree that having that option is
> good,
> but there still might not even be consensus on the "syntax".
>
> Maybe just some straw poll to gauge interest in the general feature
> would be more appropriate?
>
> Christoph
>

That's exactly what this is: a straw poll on the feature itself.

Niels Dossche

2 years ago

On 04/08/2024 15:09, Nick Lockheart wrote:

> Good morning all:
>
> When calling functions from the *global* namespace, the PHP parser
> creates opcodes that use those functions directly. When those functions
> are certain built-in functions, the parser can use special opcodes that
> are optimized for those function calls.
>
> When calling functions from *within* a namespace, the parser does not
> know at compile time if the function is defined in the current
> namespace or if the global function will be used.
>
> Because unqualified function calls are ambiguous, the parser adds an NS
> Lookup opcode which performs a runtime check for the function name in
> the current namespace, and then falls back to the global namespace if
> the function is not defined locally.
>
> This also prevents the parser from using dedicated opcodes for built-in
> functions.
>
> This incurs a performance penalty.
>
> In the past, RFCs that aimed to address this issue got too hung up on a
> syntax discussion, rather than a simple “should we solve this” question
> proposed to the community.
>
> I would like to discuss and then vote on this proposal as a feature,
> without getting into any specifics of syntax.
>
> I propose that we vote yes/no on if there should be some way, whatever
> that way ends up being, to tell the parser to always treat unqualified
> function names as global.
>
> I think it's important to get a “clean vote” on this issue, to separate
> out if past objections were objections to the concept, or if only the
> syntax proposed in past discussions was disfavored.
>
> To that end, I have created the following RFC:
>
> https://wiki.php.net/rfc/global_function_parser_directive
> I am asking that we discuss and vote on the following question:
>
> “Should there be some way for developers to signal to the parser at
> compile time that all unqualified function names found in a namespace
> context are global, without a namespace lookup?”
>
> Yes: We should do this, let's discuss syntax possibilities.
>
> No: This should not be a feature at all.
>
> Thank you for your consideration.

Hi Nick

I'm not sure how I feel about adding an additional signaling / syntax system
to signal the parser to change the behaviour of function lookup.
It means people have to take into account that a fundamental behaviour can be changed.
PHP is already hard to use IMHO because of many things you have to keep into the
back of your head, and adding something like this adds even more complexity.
If we're going to make such a change I'd rather have it unconfigurable.

Kind regards
Niels

Nick Lockheart

2 years ago

> >
> > “Should there be some way for developers to signal to the parser at
> > compile time that all unqualified function names found in a
> > namespace
> > context are global, without a namespace lookup?”
> >
> > Yes: We should do this, let's discuss syntax possibilities.
> >
> > No: This should not be a feature at all.
> >
> > Thank you for your consideration.
>
> Hi Nick
>
> I'm not sure how I feel about adding an additional signaling / syntax
> system
> to signal the parser to change the behaviour of function lookup.
> It means people have to take into account that a fundamental
> behaviour can be changed.
> PHP is already hard to use IMHO because of many things you have to
> keep into the
> back of your head, and adding something like this adds even more
> complexity.
> If we're going to make such a change I'd rather have it
> unconfigurable.
>
> Kind regards
> Niels

My thought was that it would have some clean and simple syntax, like:

namespace foo using global functions;
class MyClass{

}

When the parser hits that token, it just sets a flag and acts like
every unqualified classname has a backslash in front of it.

For everyone else:

namespace foo;
class MyClass{

}

...would still work exactly the same as it does now. And would keep BC.

Nick Lockheart

2 years ago

> My thought was that it would have some clean and simple syntax, like:
>
> namespace foo using global functions;
> class MyClass{
>
> }
>
> When the parser hits that token, it just sets a flag and acts like
> every unqualified classname has a backslash in front of it.
>
> For everyone else:
>
> namespace foo;
> class MyClass{
>
> }
>
> ...would still work exactly the same as it does now. And would keep
> BC.

Edit: Meant to say "function name" not "class name", sorry.

Derick Rethans

2 years ago

On Sun, 4 Aug 2024, Nick Lockheart wrote:

> https://wiki.php.net/rfc/global_function_parser_directive I am asking
> that we discuss and vote on the following question:
>
> “Should there be some way for developers to signal to the parser at
> compile time that all unqualified function names found in a namespace
> context are global, without a namespace lookup?”

I don't beleive that we should introduce a switch for this at all, just
like the conclusion was in https://wiki.php.net/rfc/use_global_elements

cheers,
Derick

Nick Lockheart

2 years ago

On Mon, 2024-08-05 at 12:27 +0100, Derick Rethans wrote:

> On Sun, 4 Aug 2024, Nick Lockheart wrote:
>
> > https://wiki.php.net/rfc/global_function_parser_directive I am
> > asking
> > that we discuss and vote on the following question:
> >
> > “Should there be some way for developers to signal to the parser at
> > compile time that all unqualified function names found in a
> > namespace
> > context are global, without a namespace lookup?”
>
> I don't beleive that we should introduce a switch for this at all,
> just
> like the conclusion was in
> https://wiki.php.net/rfc/use_global_elements
>
>

In that RFC, the proposal was:

declare(function_and_const_lookup='global');

I'm not sure the conclusion was that there shouldn't be a way to
control the NS lookup behavior. That's what I'm trying to determine
with this new RFC: whether it was the entire concept, or just the
syntax or mechanism that was disfavored.

Do people agree that there should be *some way* to use only global
functions without an NS lookup as a *concept*?

Or, did they not like the syntax of:

declare(function_and_const_lookup='global');

?


Because that RFC has four things in it:

(1) A Concept that global functions should be used without an NS lookup
(2) A Concept that global *constants* should be usable without an NS
lookup.
(3) A syntax being proposed.
(4) The idea that functions and constants should both be controlled by
the same directive.


I think that other RFC was on the right page, for the most part, but I
think the syntax could be improved.

Which is why I had suggested a new keyword as part of the namespace
declaration in some of my other posts.

Something that would look like one of these:

// Disable NS lookup; use all *global* functions unless
// a \foo\ appears before the function name:

namespace foo using global functions;


// Disable NS lookup; use all *local* functions unless
// a \ appears before the function name:

namespace foo using local functions;


// Use NS lookup. Same as today, no BC break:
namespace foo;