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.
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
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.
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
“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.
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.
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
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;