Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[tyson andre]

> Thanks. It's a bit strange to read the objections to the proposal in the RFC.
> That makes it feel like "we" agreed on them - while it's "only" the author's 
> opinion. From this part in the RFC:

It's included because https://wiki.php.net/rfc/howto mentions the following:

"Listen to the feedback, and try to answer/resolve all questions.
Update your RFC to document all the issues and discussions.
*Cover both the positive and negative arguments.* Put the RFC URL into all your 
replies."

This is why I included major points from the arguments for/against
in https://wiki.php.net/rfc/use_global_elements

> > and changing that default would require changing a lot of third party code.
>
> not unless it's opt-in, which it is.

Good point, I've changed this to be clearer about what I meant and add missing 
details..

> It's fairly common for NS\SubNS\ClassName to mention other classes from 
> NS\SubNS\OtherClassName right now,
> (more commonly than use Exception, use Throwable, etc in some cases),
> and [opting into that a single setting such as declare(global_lookup=1)]
> would require changing a lot of third party code [to get unambiguous function 
> and constant resolution easily].
> A separate option such as `declare(lookup_classes=global)` would allow 
> migrating to that,
> but would confuse developers switching between codebases using different 
> settings of lookup_classes,
> and introduce similar confusion about the rare case of multiple classes in 
> one file.

> > A separate option such as `declare(lookup_classes=global)` would allow 
> > migrating to that,
>
> better have lesser declare() directives IMHO.

It's impossible to agree on everything. I don't believe anyone's actively 
working on `lookup_classes` or `global_lookup` right now,
so there might still be only one declare directive for name lookup a long time 
from now.

> but would confuse developers switching between codebases using different 
> settings of lookup_classes,
> and introduce similar confusion about the rare case of multiple classes in 
> one file.

Not sure how this would be different than any other declare directive - either 
the currently proposed one or even strict_mode.


https://wiki.php.net/rfc/use_global_elements is opt-in, and also doesn't need 
to deprecate anything. The link you mention
is a different proposal that has deprecations for constants and functions.

> > > I'm not comfortable with having a 3-ways declare directive. Who will pick 
> > > which of the 3 and for what reason?
> > > That's going to be a mess to review. If we're looking for a forward path, 
> > > there should be only one opt-in way: a boolean flag.
>
> > I'm not sure what you mean by 3 ways. It's at most two, and a setting for 
> > global name lookup might become mutually exclusive (forbid using both 
> > setting names)
>
> I meant 'default', 'fallback', 'global', and declare()-omitted. Rowan's 
> latest message is a better ground to discuss this so let's continue there - I 
> share his concerns.

For the reasons I mentioned earlier, I don't want to add a 'fallback' setting 2 
ways either,
because it'd potentially constrain other RFCs unrelated to this one in ways I 
can't anticipate.
(e.g. will they emit a deprecation notice for 'fallback' and suggest using 
'fallback_v2' or a new 'default'?)

> > You mention this should be another RFC. But process-wise, I think it would 
> > be better to vote only once on a specific topic, vs having several 
> > iterations that undo previous RFCs before having a stable consensus.
>
> The issue with that is that there's no good way to set up a vote or poll for 
> that in the RFC structure.
>
> For sure, I'm not suggesting to add a sub-vote. I think we should be able to 
> discuss the best proposal we can imagine all together and put it under a 
> yes/no vote.

- There were a lot of edge cases to work out for functions and constants, and 
many approaches to dealing with that.

  There would similarly be edge cases for classes, and the same approach of 
adding `use MyNS\MyName;`
  before the class declaration `class MyName` would have other objections,
  and would probably also affect the resolution of
  namespaces (`MyName\MySubNS\MyActualClass` and `MyName\my_function()`
- Implementing and discussing changes to class resolution to see if they would 
be viable or has unexpected edge cases (while creating a proposal before voting 
on it) is time intensive.

  If I expect a vote on additionally changing class resolution to fail due to 
the edge cases and drawbacks I mentioned
  or objections to the final proposal, there's less incentive to personally do 
that work,
  and I'm not aware of other developers working on a detailed proposal for 
changing class resolution.

  The alternative of not creating an implementation it and not creating a draft 
RFC before voting would lead people to vote on something with an incomplete 
understanding
  of the impacts and viability of changing class (and possibly namespace) 
resolut

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[Nicolas Grekas]

Le lun. 27 janv. 2020 à 16:10, tyson andre  a
écrit :

> > can we please discuss this alternative? In another reply, you link to
> https://wiki.php.net/rfc/use_global_elements#deprecate_the_fallback_to_the_root_namespace_instead
> >
> > But this new proposal derived from Nikita's idea is different as it
> doesn't need to deprecate anything.
>
> I've added
> https://wiki.php.net/rfc/use_global_elements#add_setting_to_make_all_name_lookups_global_instead_eg_declare_global_lookup_1
> to the discussion notes for the RFC.
>

Thanks. It's a bit strange to read the objections to the proposal in the
RFC. That makes it feel like "we" agreed on them - while it's "only" the
author's opinion. From this part in the RFC:

> and changing that default would require changing a lot of third party
code.

not unless it's opt-in, which it is.

> A separate option such as `declare(lookup_classes=global)` would allow
migrating to that,

better have lesser declare() directives IMHO.

> but would confuse developers switching between codebases using different
settings of lookup_classes,
> and introduce similar confusion about the rare case of multiple classes
in one file.

Not sure how this would be different than any other declare directive -
either the currently proposed one or even strict_mode.


https://wiki.php.net/rfc/use_global_elements is opt-in, and also doesn't
> need to deprecate anything. The link you mention
> is a different proposal that has deprecations for constants and functions.
>
> > I'm not comfortable with having a 3-ways declare directive. Who will
> pick which of the 3 and for what reason?
> > That's going to be a mess to review. If we're looking for a forward
> path, there should be only one opt-in way: a boolean flag.
>
> I'm not sure what you mean by 3 ways. It's at most two, and a setting for
> global name lookup might become mutually exclusive (forbid using both
> setting names)
>

I meant 'default', 'fallback', 'global', and declare()-omitted. Rowan's
latest message is a better ground to discuss this so let's continue there -
I share his concerns.

BTW, should we use the word "root" instead of "global"? "global" might have
a bad connotation, and "root" is the word used in the description of the
current behavior of PHP:

declare(function_and_const_lookup='root')


> You mention this should be another RFC. But process-wise, I think it
> would be better to vote only once on a specific topic, vs having several
> iterations that undo previous RFCs before having a stable consensus.
>
> The issue with that is that there's no good way to set up a vote or poll
> for that in the RFC structure.
>

For sure, I'm not suggesting to add a sub-vote. I think we should be able
to discuss the best proposal we can imagine all together and put it under a
yes/no vote.

Reusing the "root" word, I think we might want to upgrade the current
proposal to:

declare(root_lookup=1)


I'd see global_lookup=1 and function_and_const_lookup='global' as being
> significantly different in who would vote on them.
> The former requires a lot more refactoring and code changes to handle
> changes to class name resolution,
> compared to the code changes of just changing function and constant
> resolution.
>

No proposal requires any refactoring if things are opt-in: existing
codebases will continue to work as-is. New ones might start with the new
declare directive. Existing codebases could also adopt the directive once
the tooling is ready. Eg. php-cs-fixer has all the required infrastructure
to automate this transition *for authors that want to do it*.



> And because changing resolution of class names has those drawbacks, I
> don't plan to change direction within this RFC.
>

I don't see these as drawbacks, especially when the target is cleaning up
the rules of the engine for a better future :)

Can you please consider it? While this reply might feel like I'm "just"
criticizing your work, it's not: I'm very thankful for what you're doing
here and I think you are doing a great job. I'm "just" trying to help shape
the best proposal for the best future of PHP, although very modestly :)

Doesn't anyone else share my points?

Nicolas

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[tyson andre]

> 1. Is it a typo that the first code example in the proposal has a
> namespace declaration before the `declare` statement? Currently it is
> a fatal error if a `strict_types` declaration isn't the first
> statement in a file. Are you intending to change this restriction,
> or have it not apply to the `function_and_const_lookup` declaration?

Thanks, fixed. This statement order was wrong and from a previous revision of 
the RFC.
The restriction for `strict_types` won't change.

> 2. How will this RFC fit into "future work on autoloading" (mentioned
> as a benefit in the discussion section)? Would autoloading only be
> possible for files with `declare(function_and_const_lookup='global');`?
>
> This RFC seems like a pragmatic attempt to solve the global/namespaced
> ambiguity issue for the way code is typically written today (most
> const/function uses in a namespace being global yet unqualified).
> However, isn't the current lack of autoloading part of the reason for
> this usage pattern? Personally I would love to write more plain
> functions in namespaces, but am forced to use static class methods
> instead to benefit from autoloading.

A major objection to autoloading for functions and constants is that it's
unpredictable for ambiguous elements.
(so one way to implement autoloading is to *only autoload if the reference to a
function or constant is unambiguous*)
Right now, it's possible but inconvenient for projects to unambiguously refer 
to functions and constants,
for the reasons mentioned in 
https://wiki.php.net/rfc/use_global_elements#introduction
Implementing this RFC makes removing this ambiguity much easier.

I wouldn't want autoloading to be limited to just files with 
function_and_const_lookup='global'

> In other words, if PHP had function autoloading, there would be more
> usage of namespaced functions, in which case changing function and
> const lookup to global becomes less helpful. In this way the RFC seems
> to work against one of its own goals.

Yes, there would be more usage of namespaced functions.
However, right now, most of the references to classes are to classes in 
different namespaces.
Most of the references to functions are in the global namespace,
and of the references to functions outside of the global namespace,
I'd guess that most are from a namespace *different* from the current namespace.

The other goal of this RFC is to make unambiguous references convenient.
"[Manually using names from the global namespace] is prone to merge conflicts
when functions start/stop being used, inconvenient to keep up to date,
and the vast majority of the uses will be global functions and constants."

> I would find it quite annoying and counterintuitive to have to
> explicitly `use` namespaced functions and consts in the same file
> they are defined in. The example in the RFC of a function defined in
> a namespace that appears to call itself but actually calls a different
> global function is particularly confusing.

Requiring `use function MyNS\sprintf;` before the declaration of a function 
named `sprintf`
outside of the global namespace is planned for the final version of this RFC.
Same for constants.

- You can use `='default'` or omit it in the files that declare functions and 
constants
  if you don't want that.

That example illustrates edge cases that had to be dealt with
in the RFC's implementation, and I'd expect code like that to be uncommon.

Making the name resolution behavior easy to understand and not have surprising 
special cases
was the main reasoning for implementing it this way.
It shouldn't matter which function gets declared first,
whether functions are reordered when refactoring,
or if the body of a function gets moved to a different file.

> I'd really like to see a more complete proposal that thinks through
> how it will fit in with future autoloading and the way people will
> then write code, rather than just the way they write it today due to
> current limitations.
>
> Long term I think it would be better to have a `declare(global_lookup=0)`
> option which could be applied to a set of namespaces, and a registered
> function/const autoloader would only be triggered for those namespaces.
> This would allow function autoloading to be used without hurting performance 
> or breaking existing libraries.

This was brought up in earlier discussion, in 
https://wiki.php.net/rfc/use_global_elements#deprecate_fallback_to_the_root_namespace_instead
Also see https://externals.io/message/107953#107962

The "module system" idea also brought up the desire for a more complete 
proposal.
Right now, though, a more complete proposal hasn't been created.

Using `declare(global_lookup=0)` would not fix the current drawbacks of 
unambiguously
referencing functions or constants that motivated me
to create this RFC (in 
https://wiki.php.net/rfc/use_global_elements#introduction)

Thanks,
- Tyson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.n

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[Theodore Brown]

On Sun, Jan 26, 2020 at 10:25 AM tyson andre  wrote:

> https://wiki.php.net/rfc/use_global_elements and the implementation
> has been updated again - the syntax is now 
> declare(function_and_const_lookup='global')
> with a literal string instead of a keyword.

> The voting option for whether it was a string or a keyword was removed.
> I plan to move this to the voting phase on Monday, if nothing else
> needs to be addressed

I have a few questions and concerns:

1. Is it a typo that the first code example in the proposal has a
namespace declaration before the `declare` statement? Currently it is
a fatal error if a `strict_types` declaration isn't the first
statement in a file. Are you intending to change this restriction,
or have it not apply to the `function_and_const_lookup` declaration?

2. How will this RFC fit into "future work on autoloading" (mentioned
as a benefit in the discussion section)? Would autoloading only be
possible for files with `declare(function_and_const_lookup='global');`?

This RFC seems like a pragmatic attempt to solve the global/namespaced
ambiguity issue for the way code is typically written today (most
const/function uses in a namespace being global yet unqualified).
However, isn't the current lack of autoloading part of the reason for
this usage pattern? Personally I would love to write more plain
functions in namespaces, but am forced to use static class methods
instead to benefit from autoloading.

In other words, if PHP had function autoloading, there would be more
usage of namespaced functions, in which case changing function and
const lookup to global becomes less helpful. In this way the RFC seems
to work against one of its own goals.

I would find it quite annoying and counterintuitive to have to
explicitly `use` namespaced functions and consts in the same file
they are defined in. The example in the RFC of a function defined in
a namespace that appears to call itself but actually calls a different
global function is particularly confusing.

I'd really like to see a more complete proposal that thinks through
how it will fit in with future autoloading and the way people will
then write code, rather than just the way they write it today due to
current limitations.

Long term I think it would be better to have a `declare(global_lookup=0)` 
option which could be applied to a set of namespaces, and a registered
function/const autoloader would only be triggered for those namespaces.
This would allow function autoloading to be used without hurting performance or 
breaking existing libraries.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[tyson andre]

> can we please discuss this alternative? In another reply, you link to 
> https://wiki.php.net/rfc/use_global_elements#deprecate_the_fallback_to_the_root_namespace_instead
> 
> But this new proposal derived from Nikita's idea is different as it doesn't 
> need to deprecate anything.

I've added 
https://wiki.php.net/rfc/use_global_elements#add_setting_to_make_all_name_lookups_global_instead_eg_declare_global_lookup_1
 to the discussion notes for the RFC.

https://wiki.php.net/rfc/use_global_elements is opt-in, and also doesn't need 
to deprecate anything. The link you mention
is a different proposal that has deprecations for constants and functions.

> I'm not comfortable with having a 3-ways declare directive. Who will pick 
> which of the 3 and for what reason?
> That's going to be a mess to review. If we're looking for a forward path, 
> there should be only one opt-in way: a boolean flag.

I'm not sure what you mean by 3 ways. It's at most two, and a setting for 
global name lookup might become mutually exclusive (forbid using both setting 
names)

https://wiki.php.net/rfc/use_global_elements is 1 way right now. 
`declare(function_and_const_lookup='global')`
If anyone made a proposal for class names in the future, it would probably be 2 
way.

> If we were to make such a change (hypothetically), the way I would view it
> is "use new name resolution rules" or not, rather than a collection of
> fine-grained options.

As it understand it, "use new name resolution rules" (a single RFC for 
everything, including class names)
is a discussion on how name resolutions could be changed to measure interest 
and get arguments for/against,
and not something being advanced as an RFC right now.

> I think that's all we need to make all symbols resolve in the same way, known 
> at compile time.
> 
> You mention this should be another RFC. But process-wise, I think it would be 
> better to vote only once on a specific topic, vs having several iterations 
> that undo previous RFCs before having a stable consensus.

The issue with that is that there's no good way to set up a vote or poll for 
that in the RFC structure.
I'd see global_lookup=1 and function_and_const_lookup='global' as being 
significantly different in who would vote on them.
The former requires a lot more refactoring and code changes to handle changes 
to class name resolution,
compared to the code changes of just changing function and constant resolution.
The reason I'm not trying to make a secondary vote on this is similar to the 
reasons why "use function..." vs "declare()" was a bad idea to vote on in a 
previous version of my RFC.

And because changing resolution of class names has those drawbacks, I don't 
plan to change direction within this RFC.

> I don't think it's a good idea to resolve the question of "use global
> functions" vs "declare" as a subsidiary vote. At least in my mind, those
> two options are significantly different, and this choice would affect both
> my overall opinion of the proposal and also the answer I would give on some
> of the other voted question.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[Nicolas Grekas]

Le ven. 24 janv. 2020 à 17:10, Nicolas Grekas 
a écrit :

>
> One option that I haven't seem much discussion on is the opposite: Always
>> only look in the global namespace. Any unimported unqualified usages will
>> be treated as fully qualified names. This would match the proposed
>> semantics for functions/consts and change the resolution rules for
>> classes.
>> I think this would have relatively little impact on how code is written,
>> as
>> classes already tend to make extensive use of cross-namespace references
>> and the import is usually IDE managed.
>>
>
>
> Quick reaction: that'd make sense to me!
>
> Adding a "use CurrentNamespace\Foo" or using "namespace\Foo" looks easy
> enough to adopt.
> Does this mean you're suggesting to use declare(symbol_lookup='global')?
> Or shorter: declare(lookup='global'), or maybe even
> declare(global_lookup=1) as I'm not sure we need 3 options here?
>

Hello Tyson,

can we please discuss this alternative? In another reply, you link to
https://wiki.php.net/rfc/use_global_elements#deprecate_the_fallback_to_the_root_namespace_instead

But this new proposal derived from Nikita's idea is different as it doesn't
need to deprecate anything.

I'm not comfortable with having a 3-ways declare directive. Who will pick
which of the 3 and for what reason? That's going to be a mess to review. If
we're looking for a forward path, there should be only one opt-in way: a
boolean flag.

declare(global_lookup=1)

I think that's all we need to make all symbols resolve in the same way,
known at compile time.

You mention this should be another RFC. But process-wise, I think it would
be better to vote only once on a specific topic, vs having several
iterations that undo previous RFCs before having a stable consensus.

Thanks for considering,
Nicolas

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[tyson andre]

Hi internals,

https://wiki.php.net/rfc/use_global_elements and the implementation has been 
updated again - the syntax is now declare(function_and_const_lookup='global')
with a literal string instead of a keyword.
The voting option for whether it was a string or a keyword was removed.

I plan to move this to the voting phase on Monday, if nothing else needs to be 
addressed

> Saving two characters per file doesn't seem like a great motivation to add 
> additional special cases to core language syntax.
> Right now, declare just types "identifier = expr", while with this change 
> it's going to be "identifier = (expr | a | few | extra | keywords)".

Thinking about it again, I'd agree with the parsing special cases being 
inconvenient.

> So, most references are to classes outside the current namespace. The number 
> of references to global classes and classes in the same namespace is actually 
> pretty similar, there are 5% more global references.
> From that perspective, changing the name resolution rules to always look for 
> the global symbol if unimported would actually slightly reduce the number of 
> necessary "use" statements.

It would be more understandable for new php developers familiar with other 
languages if name lookup was consistent across classes.

I don't have as strong a use case for this as I do for eliminating the 
function/const ambiguity. Changing class resolution (via automated tool) would 
require more code changes than function/constant resolution, and the classes 
are already unambiguous.

> If we were to make such a change (hypothetically), the way I would view it is 
> "use new name resolution rules" or not, rather than a collection of 
> fine-grained options.
> Notably Rust made a major change to how symbols are
> resolved in the 2018 edition, so
> such things aren't inconceivable, especially with the right tooling.

If a setting affecting all name resolution was added, then forbidding the use 
of both that new setting (e.g. ) and 
declare(function_and_const_lookup) in the same file would keep code simpler.

If "use new name resolution rules" was the only option, the larger amount of 
refactoring for class references (and doc comments) might discourage using the 
new name resolution for functions/constants, and make backporting patches to 
previous major versions of applications/libraries more error prone (e.g. 
\MyNS\Exception vs \Exception). The refactoring might also be perceived as 
risky.
So I'd still want to see the voting results&feedback for 
function_and_const_lookup before investigating approaches to changing class 
resolution.

Rust would also catch many more possible bugs in symbol resolution at compile 
time.
The static analyzers for PHP can detect almost as many bugs, but would require 
that people be aware of the analyzers, configure them, and use them in CI.

- Code such as if (class_exists(SomeClass::class)) { /* Use SomeClass */ } 
might be permitted if analyzing class_exists conditionals is a feature of a 
static analyzer.

- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[Nikita Popov]

On Fri, Jan 24, 2020 at 6:58 PM tyson andre 
wrote:

> > I like the idea of using a meaningful value here, but think that this
> > should be using a string, i.e.
> declare(function_and_const_lookup='global')
> > rather than declare(function_and_const_lookup=global). Currently
> declare()
> > syntax uses a normal constant expression on the right hand side of the =,
> > and I don't see a strong reason why we should deviate from that for this
> > feature. An existing declare using a string is declare(encoding='UTF-8').
>
> Whether it's quoted is a low priority to me - I went with the unquoted
> implementation
> because it might be something repeated in every file of a project,
> and it'd be slightly more convenient to avoid quotes and use keywords if
> there were
> many more settings with different values (=on, =off, =warning, etc) in the
> future.
> A difference is that it makes sense to quote encodings such as UTF-8
> because of the '-',
> but not as much to quote keywords without special characters.
>

Saving two characters per file doesn't seem like a great motivation to add
additional special cases to core language syntax. Right now, declare just
types "identifier = expr", while with this change it's going to be
"identifier = (expr | a | few | extra | keywords)".

> > One option that I haven't seem much discussion on is the opposite:
Always only look in the global namespace. Any unimported unqualified usages
will be treated as fully qualified names.
> > This would match the proposed semantics for functions/consts and change
the resolution rules for classes.
> > I think this would have relatively little impact on how code is
written, as classes already tend to make extensive use of cross-namespace
references and the import is usually IDE managed.
>
> It's fairly common for NS\SubNS\ClassName to mention other classes from
NS\SubNS\OtherClassName right now,
> (more commonly than use Exception, use Throwable, etc in some cases),

Out of interest, I checked how the symbol reference distribution in
open-source projects look like. These numbers are for unique class name
references inside namespaces:

Global: int(88398)
Same namespace: int(83790)
Other namespace: int(315455)

So, most references are to classes outside the current namespace. The
number of references to global classes and classes in the same namespace is
actually pretty similar, there are 5% more global references.

>From that perspective, changing the name resolution rules to always look
for the global symbol if unimported would actually slightly reduce the
number of necessary "use" statements.

> and changing that default would require changing a lot of third party
code.
> A separate option such as `declare(lookup_classes=global)` would allow
migrating to that,
> but would confuse developers switching between codebases using different
settings of lookup_classes,
> and introduce similar confusion about the rare case of multiple classes
in one file.

If we were to make such a change (hypothetically), the way I would view it
is "use new name resolution rules" or not, rather than a collection of
fine-grained options. Notably Rust made a major change to how symbols are
resolved in the 2018 edition, so such things aren't inconceivable,
especially with the right tooling.

Nikita

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[tyson andre]

> I like the idea of using a meaningful value here, but think that this
> should be using a string, i.e. declare(function_and_const_lookup='global')
> rather than declare(function_and_const_lookup=global). 

Also, I could make that a voting option, and it could be changed before 8.0 
alphas if new concerns come up after a vote.

> This looks a bit peculiar... We could also say that declaring a symbol also 
> automatically brings it into scope.
> I'm not really sure which is better.

Neither am I. There were edge cases with doing that that may cause more 
confusion

namespace NS;
function f() { /* calls g() - which g() */ }
function g() { /* calls f() */ }

if (!function_exists('NS\h')) {
function h() {}
} else {
// what will h() refer to
} 
// what will h() refer to

> As a general note on the overall proposal: I think this is a very pragmatic 
> proposal. It addresses a real issue, and it addresses it in the most 
> straightforward way. You can just drop the declare in your code, and it will 
> keep working exactly as it did
> before, just faster. Assuming you weren't doing anything stupid, of course.
>
> The big downside is that this makes class and function symbol resolution 
> complete opposites. Classes only look in the current namespace. Functions 
> only look in the global namespace. This reflects the way they are most 
> commonly used, but is not a great
 place to end up from a language design perspective.
>
There are two alternatives that keep class and function symbol resolution the 
same: One is to always only look in the namespace. This has been suggested a 
few times in the past, including in this thread, and the RFC
https://wiki.php.net/rfc/fallback-to-root-scope-deprecation. I think this is a 
fairly unpopular option, because using fully qualified names for functions 
tends to be quite ugly (more
 so than for classes, due to the positions they're used in), or requires a 
large number of imports, as even a small piece of code can easily use a dozen 
different string/array functions.

Agreed

> One option that I haven't seem much discussion on is the opposite: Always 
> only look in the global namespace. Any unimported unqualified usages will be 
> treated as fully qualified names.
> This would match the proposed semantics for functions/consts and change
 the resolution rules for classes.
> I think this would have relatively little impact on how code is written, as 
> classes already tend to make extensive use of cross-namespace references and 
> the import is usually IDE managed.

Also, about the note on classes.

It's fairly common for NS\SubNS\ClassName to mention other classes from 
NS\SubNS\OtherClassName right now,
(more commonly than use Exception, use Throwable, etc in some cases),
and changing that default would require changing a lot of third party code.
A separate option such as `declare(lookup_classes=global)` would allow 
migrating to that,
but would confuse developers switching between codebases using different 
settings of lookup_classes,
and introduce similar confusion about the rare case of multiple classes in one 
file.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[tyson andre]

> > One option that I haven't seem much discussion on is the opposite: Always
> only look in the global namespace. Any unimported unqualified usages will
> > be treated as fully qualified names. This would match the proposed
> > semantics for functions/consts and change the resolution rules for classes.
> > 
> > I think this would have relatively little impact on how code is written, as
> > classes already tend to make extensive use of cross-namespace references
> > and the import is usually IDE managed.
> 
> Quick reaction: that'd make sense to me!
> 
> Adding a "use CurrentNamespace\Foo" or using "namespace\Foo" looks easy 
> enough to adopt.
> Does this mean you're suggesting to use 
> declare(symbol_lookup='global')? Or shorter: declare(lookup='global'), or
> maybe even declare(global_lookup=1) as I'm not sure we need 3 options here?

The RFC has been updated after feedback, but I forgot to update the wiki and PR 
title.

I sent out an email last week mentioning that 
https://wiki.php.net/rfc/use_global_elements
is now a single `declare()` setting `declare(function_and_const_lookup=global)`

> Always only look in the global namespace.

Other RFCs have proposed that approach.
I mentioned the objections others had to that RFC in
https://wiki.php.net/rfc/use_global_elements#deprecate_the_fallback_to_the_root_namespace_instead

"Deprecating the behavior of existing code would break (possibly unmaintained) 
third-party libraries
and require a lot of code changes, discouraging updates to the latest version 
of PHP."

> I like the idea of using a meaningful value here, but think that this
> should be using a string, i.e. declare(function_and_const_lookup='global')
> rather than declare(function_and_const_lookup=global). Currently declare()
> syntax uses a normal constant expression on the right hand side of the =,
> and I don't see a strong reason why we should deviate from that for this
> feature. An existing declare using a string is declare(encoding='UTF-8').

Whether it's quoted is a low priority to me - I went with the unquoted 
implementation
because it might be something repeated in every file of a project,
and it'd be slightly more convenient to avoid quotes and use keywords if there 
were
many more settings with different values (=on, =off, =warning, etc) in the 
future.
A difference is that it makes sense to quote encodings such as UTF-8 because of 
the '-',
but not as much to quote keywords without special characters.

> It looks like the implementation has been updated to the style proposed
> here, while the RFC still uses disable_ambiguous_element_lookup.

Fixed, forgot to update the wiki after updating the implementation
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[Nicolas Grekas]

> One option that I haven't seem much discussion on is the opposite: Always
> only look in the global namespace. Any unimported unqualified usages will
> be treated as fully qualified names. This would match the proposed
> semantics for functions/consts and change the resolution rules for classes.
> I think this would have relatively little impact on how code is written, as
> classes already tend to make extensive use of cross-namespace references
> and the import is usually IDE managed.
>


Quick reaction: that'd make sense to me!

Adding a "use CurrentNamespace\Foo" or using "namespace\Foo" looks easy
enough to adopt.
Does this mean you're suggesting to use declare(symbol_lookup='global')? Or
shorter: declare(lookup='global'), or maybe even declare(global_lookup=1)
as I'm not sure we need 3 options here?

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[Nikita Popov]

On Sat, Jan 18, 2020 at 11:53 PM tyson andre 
wrote:

> > I'd much rather have something like:
> >
> > declare(ambiguous_element_lookup=0)
> >
> > declare(ambiguous_element_lookup=off)
>
> Aside: declare(unambiguous_element_lookup=1) is probably a better choice
> than my first choice of (disable_ambiguous_element_lookup=1), but probably
> not the best choice.
>
> > I find that the “disable_ambiguous_element_lookup” directive name is,
> well, ambiguous.
> > Does it mean that it will look up only in the current namespace, or only
> in the global namespace? I can’t guess.
> >
> > Maybe a three-value directive:
> >
> >declare(function_and_const_lookup=global);
> >declare(function_and_const_lookup=namespace);
> >declare(function_and_const_lookup=fallback); // the default
>
> That's my favorite setting name overall so far - it ends up being as long
> as disable_ambiguous_element_lookup and more self-explanatory.
> I don't plan to include namespace-only in the RFC - future RFCs could
> propose additional values independently.
>
> Probably just `= global` and `= default`, because the default might
> eventually change (from the fallback),
> and = fallback could be added if the old fallback was desirable enough.
> - `= default` would only be useful to set resolution back to the default
>   with future language changes such as
> https://wiki.php.net/rfc/namespace_scoped_declares#implementation_considerations
>

It looks like the implementation has been updated to the style proposed
here, while the RFC still uses disable_ambiguous_element_lookup.

I like the idea of using a meaningful value here, but think that this
should be using a string, i.e. declare(function_and_const_lookup='global')
rather than declare(function_and_const_lookup=global). Currently declare()
syntax uses a normal constant expression on the right hand side of the =,
and I don't see a strong reason why we should deviate from that for this
feature. An existing declare using a string is declare(encoding='UTF-8').

The RFC says:

function sprintf($msg, ...$args) {
// this and remaining statements still refer to \sprintf, not
MyNS\sprintf
return sprintf("Prefix $msg", ...$args);
}

This looks a bit peculiar... We could also say that declaring a symbol also
automatically brings it into scope. I'm not really sure which is better.

As a general note on the overall proposal: I think this is a very pragmatic
proposal. It addresses a real issue, and it addresses it in the most
straightforward way. You can just drop the declare in your code, and it
will keep working exactly as it did before, just faster. Assuming you
weren't doing anything stupid, of course.

The big downside is that this makes class and function symbol resolution
complete opposites. Classes only look in the current namespace. Functions
only look in the global namespace. This reflects the way they are most
commonly used, but is not a great place to end up from a language design
perspective.

There are two alternatives that keep class and function symbol resolution
the same: One is to always only look in the namespace. This has been
suggested a few times in the past, including in this thread, and the RFC
https://wiki.php.net/rfc/fallback-to-root-scope-deprecation. I think this
is a fairly unpopular option, because using fully qualified names for
functions tends to be quite ugly (more so than for classes, due to the
positions they're used in), or requires a large number of imports, as even
a small piece of code can easily use a dozen different string/array
functions.

One option that I haven't seem much discussion on is the opposite: Always
only look in the global namespace. Any unimported unqualified usages will
be treated as fully qualified names. This would match the proposed
semantics for functions/consts and change the resolution rules for classes.
I think this would have relatively little impact on how code is written, as
classes already tend to make extensive use of cross-namespace references
and the import is usually IDE managed.

Regards,
Nikita

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[tyson andre]

> I'd much rather have something like:
>
> declare(ambiguous_element_lookup=0)
> 
> declare(ambiguous_element_lookup=off)

Aside: declare(unambiguous_element_lookup=1) is probably a better choice than 
my first choice of (disable_ambiguous_element_lookup=1), but probably not the 
best choice.

> I find that the “disable_ambiguous_element_lookup” directive name is, well, 
> ambiguous.
> Does it mean that it will look up only in the current namespace, or only in 
> the global namespace? I can’t guess.
> 
> Maybe a three-value directive:
> 
>declare(function_and_const_lookup=global);
>declare(function_and_const_lookup=namespace);
>declare(function_and_const_lookup=fallback); // the default

That's my favorite setting name overall so far - it ends up being as long as 
disable_ambiguous_element_lookup and more self-explanatory.
I don't plan to include namespace-only in the RFC - future RFCs could propose 
additional values independently.

Probably just `= global` and `= default`, because the default might eventually 
change (from the fallback),
and = fallback could be added if the old fallback was desirable enough.
- `= default` would only be useful to set resolution back to the default
  with future language changes such as 
https://wiki.php.net/rfc/namespace_scoped_declares#implementation_considerations

> "namespace_lookup"

It might cause confusion when a new php programmer tries to set this setting,
and discovers that catch(Exception) {} still means MyNS\Exception with 
declare(namespace_lookup=global).
(assuming you meant something along those lines)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[Olumide Samson]

"namespace_lookup"

On Sat, Jan 18, 2020, 10:32 PM Mark Randall  wrote:

> On 18/01/2020 18:05, tyson andre wrote:
> >which is now declare(disable_ambiguous_element_lookup=1) at the top
> of a file.
>
> I_suspect_these_long_declares_might_get_tedious
>
> Can we at least agree on internals that a declare doesn't have to have a
> negative default value that is toggled on?
>
> I'd much rather have something like:
>
> declare(ambiguous_element_lookup=0)
> declare(ambiguous_element_lookup=off)
>
> --
> Mark Randall
> marand...@php.net
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[Mark Randall]

On 18/01/2020 18:05, tyson andre wrote:

   which is now declare(disable_ambiguous_element_lookup=1) at the top of a 
file.


I_suspect_these_long_declares_might_get_tedious

Can we at least agree on internals that a declare doesn't have to have a 
negative default value that is toggled on?


I'd much rather have something like:

declare(ambiguous_element_lookup=0)
declare(ambiguous_element_lookup=off)

--
Mark Randall
marand...@php.net


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[tyson andre]

Hi internals,

After feedback, the RFC syntax has been changed from `use global functions` to 
`declare(disable_ambiguous_element_lookup=1)`. In addition,

- The two settings have been combined into a single option,
  which is now declare(disable_ambiguous_element_lookup=1) at the top of a file.

  Those settings would be enabled together, in any use case I can think of.
- Declaring global functions and constants in files with 
declare(disable_ambiguous_element_lookup=1) is now allowed in any namespace,
  to allow code to continue to work even with future changes such as 
https://wiki.php.net/rfc/namespace_scoped_declares
  (and so that files declaring functions or constants can have consistent 
coding style with files that don't)
- The following voting choices have been removed: (1) the syntax and for (2) 
whether declaring functions/constants are errors

  The outcome of those votes would noticeably change the RFC and affect whether 
voters would vote for the RFC as a whole.

The RFC https://wiki.php.net/rfc/use_global_elements has been updated.
The implementation at https://github.com/php/php-src/pull/4951 has also been 
updated.

I was planning to move this to the voting stage on the 25th (1 week),
since the revised RFC is similar to the old RFC,
and arguments in favor of declare() have been mentioned for over 2 weeks.

Thanks,
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[tyson andre]

I'll be postponing the vote to update the RFC and proof of concept/tests 
associated with it to use declare()

Also, "declare(lookup_functions_in_current_namespace = false, 
lookup_consts_in_global_namespace = false)" in the file's declare() blocks was 
my first idea.
Any ideas - declare(disable_ambiguous_element_lookups=1), 
declare(disable_ambiguous_lookups_in_current_namespace=1), etc?

x=1 seems to be more common, and reflects the fact that this is not the default.

> I don't think it's a good idea to resolve the question of "use global 
> functions" vs "declare" as a subsidiary vote.
> At least in my mind, those two options are significantly different, and this 
> choice would affect both my overall opinion of the proposal
> and also the answer I would give on some of the other voted question.

Agreed, I had some of those concerns after suggesting setting it up that way.
It doesn't capture "accept if one option, but not if the other option".


Ideally, I could have a vote for the syntax to use for the RFC,
then amend the RFC with the syntax, but that isn't practical.

> The RFC already outlines a number of reasons why it is preferable to 
> implement this as a declare directive,
> so please excuse my reiterating some points here :)
> First and foremost, if we ever implement 
https://wiki.php.net/rfc/namespace_scoped_declares or some similar way of 
specifying declares on the package level,
> and I think it's pretty likely that we're going to do this in one form or 
> another, then we're very much going to regret not making this a
 declare.
> Disabling the namespace fallback, just like the use of strict types, is 
> something you will usually want to do for an entire library/project, not just 
> for individual files.
> Going for something like "use global functions" preemptively precludes this 
> for no good reason.

That's a good point. I think that's the first time I've seen that RFC.
https://wiki.php.net/rfc/namespace_scoped_declares#nesting_behavior / 
https://wiki.php.net/rfc/namespace_scoped_declares#implementation_considerations
 answers my questions about how that would work with readability/opcache.

It'd definitely be convenient to have less boilerplate.

> Second, I think phrasing the semantics in terms of a change to name 
> resolution behavior (which the declare does)
> is clearer than phrasing it as "import all functions/consts in the global 
> namespace".
> That's not really what this this feature is doing on a technical
 level, and this phrasing is what results in questions regarding the behavior 
for various conditions regarding symbol overlaps etc.
> For example, with the declare, I don't think that it should be an error to 
> make a function declaration inside a namespace
> -- that's still entirely well defined, and I think a legitimate use-case
> (a project that is disabling namespace fallback everywhere, will likely want 
> to do that for files declaring functions as well, as a matter of consistency.)

My concern was about this being well-defined but being likely to be 
accidentally misused, e.g. with namespace-scoped declares.
Same for NS\my_printf calling \my_sprintf instead of NS\my_sprintf within the 
same file.
Explicitly changing to namespace\my_sprintf() or uses would be one way to 
migrate code like that.

namespace Example;
use global functions;  // or declare()
// interpreting this literally, without `use Example\fact;` instead of 
namespace\fact, this is calling \fact(), which is surprising
// (the old equivalent `use function fact;` would throw because of the name 
reuse) 
function fact($n) { return $n > 1 ? $n * fact($n - 1) : 1; }


> Third, I'm not sure it makes sense to separate this functionality for 
> functions and for constants.
> I can't really imagine a situation where you would want to, say, use 
> namespaced constants but global functions.
> I can see why you went with this split when using the "use" syntax (as we 
> already have "use function" and "use const" both),
> but with a declare approach, I would suggest to combine both. Functions and 
> constants live in different symbol spaces,
> but their name resolution behavior is the same.

If you're declaring a function or a constant in a namespace, the way I 
implemented it would throw an Error at compile time to avoid confusion.
If it didn't throw an Error, then I'd agree that it'd virtually always be used 
together, except possibly when migrating to being stricter gradually.

> Finally, if you do want to go with the "use" syntax, "functions" and "consts" 
> should not be made reserved keywords.
> There is no technical need for these to be true keywords, so we can avoid an 
> unnecessary BC break here.

Agreed for future work on "use"
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[Nikita Popov]

On Tue, Jan 14, 2020 at 7:27 PM tyson andre 
wrote:

> > This RFC proposes to support an opt-in "use global functions/consts;"
> statement
> > to disable PHP's check for the function/const in the current namespace
> before falling back to the global namespace.
> >
> > https://wiki.php.net/rfc/use_global_elements
> >
> >
> > Earlier discussion can be found in the 'Opt-in "use function *;" for
> skipping check for
> > function/const in alternate namespace' email thread, which can be seen at
> https://externals.io/message/107877
> >Let me know if you have any comments on the RFC
>
> I plan to update the wiki and start the voting phase tomorrow with the
> voting structure mentioned in https://wiki.php.net/rfc/use_global_elements
> Alternatives/Arguments
> 
> mentioned in this thread have had summaries added in the discussion section.
>

Hi Tyson,

I don't think it's a good idea to resolve the question of "use global
functions" vs "declare" as a subsidiary vote. At least in my mind, those
two options are significantly different, and this choice would affect both
my overall opinion of the proposal and also the answer I would give on some
of the other voted question.

The RFC already outlines a number of reasons why it is preferable to
implement this as a declare directive, so please excuse my reiterating some
points here :)

First and foremost, if we ever implement
https://wiki.php.net/rfc/namespace_scoped_declares or some similar way of
specifying declares on the package level, and I think it's pretty likely
that we're going to do this in one form or another, then we're very much
going to regret not making this a declare. Disabling the namespace
fallback, just like the use of strict types, is something you will usually
want to do for an entire library/project, not just for individual files.
Going for something like "use global functions" preemptively precludes this
for no good reason.

Second, I think phrasing the semantics in terms of a change to name
resolution behavior (which the declare does) is clearer than phrasing it as
"import all functions/consts in the global namespace". That's not really
what this this feature is doing on a technical level, and this phrasing is
what results in questions regarding the behavior for various conditions
regarding symbol overlaps etc. For example, with the declare, I don't think
that it should be an error to make a function declaration inside a
namespace -- that's still entirely well defined, and I think a legitimate
use-case (a project that is disabling namespace fallback everywhere, will
likely want to do that for files declaring functions as well, as a matter
of consistency.)

Third, I'm not sure it makes sense to separate this functionality for
functions and for constants. I can't really imagine a situation where you
would want to, say, use namespaced constants but global functions. I can
see why you went with this split when using the "use" syntax (as we already
have "use function" and "use const" both), but with a declare approach, I
would suggest to combine both. Functions and constants live in different
symbol spaces, but their name resolution behavior is the same.

Finally, if you do want to go with the "use" syntax, "functions" and
"consts" should not be made reserved keywords. There is no technical need
for these to be true keywords, so we can avoid an unnecessary BC break here.

Regards,
Nikita

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[tyson andre]

> Could you expand on what you mean by "ambiguous" / "unambiguous" here?

I started the thread "Autoloading functions/consts without a performance impact"
for any other discussion on autoloading. It clarifies what "ambiguous" means.
In my earlier comments, I didn't realize https://wiki.php.net/rfc/autofunc was 
already created
and is similar to what I had in mind,
but as far as I know never had a proof of concept to vote on.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[tyson andre]

> We might eventually benefit from versioned "libraries" of functions that can 
>be imported in one command
> which would solve many-a-future-problem by itself.

I'd be in favor of a module system, I just can't think of a good way to migrate 
to that with existing limitations.
I'd imagine there would be various obstacles/objections to getting an RFC for 
that approach accepted.

Of course, whatever you're thinking of for "libraries" might
be completely different than what I think you mean.
Proposals for that could start a different thread.

For example, if one wanted a module system like NodeJS with "import functions, 
consts from 'some_native_module_or_php_file'"/"export function ..."

1. Languages such as NodeJS, Python, etc. still have a core set of functions 
that get loaded even if there are no imports.
Those functions can get added to dynamically (see note on polyfills.

https://stackoverflow.com/questions/27930038/how-to-define-global-function-in-python
 is hopefully rare)
That would be an argument in favor of preferring deprecating checking in 
the current namespace,
not deprecating the global namespace. (for uses that aren't fully qualified)
2. It's possible for almost any php module's functionality such as "mbstring" 
to be provided by a native module,
   or from a pure php polyfill such as symfony/mbstring-polyfill. 
https://www.php.net/mbstring
   Or even just a few functions from an extension.
   I don't know how the equivalent of "import [functions, consts] from 
'mbstring'" would work in a portable way,
   e.g. with a future version of the composer autoloader.
3. This would add more ambiguity if imported names can get overridden (e.g. by 
MyNs\strlen),
   making opcache less beneficial to performance.
   It would also make it harder to comprehend code if exported functions from 
modules can have aliased names.

A more limited version of "libraries" might be possible (pure php only with 
other limitations) but it doesn't seem as useful.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[Mike Schinkel]

> On Jan 1, 2020, at 11:31 PM, Mark Randall  wrote:
> In future, I think the optimal solution is opt-in deprecating fallback to the 
> root namespace using a declare. We might eventually benefit from versioned 
> "libraries" of functions that can be imported in one command which would 
> solve many-a-future-problem by itself.

+1 to that.  

Especially if there is a mechanism to define functions from other people's code 
to be included in those "libraries", such as the functions in the WordPress API.

> Id like to see nikic/scalar_objects added to the core in 8.0, that would 
> offer non-procedural (and therefore non-namespaced) access to many of the 
> most common global functions (strings, arrays etc). In turn, that would allow 
> developers to limit the number of use \... statements.

And +1000 to that!

-Mike

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[Rowan Tommins]

On Thu, 2 Jan 2020 at 05:37, tyson andre  wrote:

> Out of scope of this RFC: I had a thought today about autoloading.
> I'd rather improve function / const autoloading instead of moving to
> classes.
> What if an ambiguous function_name() or const outside the global
> namespace would attempt to autoload *ambiguous* functions in the global
> scope,
> but not the current namespace?
> (and autoload unambiguous functions in their respective scope)
>


Could you expand on what you mean by "ambiguous" / "unambiguous" here?

I think any nuance to which function is autoloaded needs to match the
actual name resolution - it wouldn't make much sense for some_function() to
call CurrentNS\some_function if already defined, but trigger an autoloader
for \some_function if not. There may be simplifications with the proposed
directive from this RFC, but we'd need to think through the different
combinations and make sure they behaved consistently and intuitively.

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[tyson andre]

> It's an interesting idea, but at this time I think it's the wrong 
> approach to what is in the best long-term interests of the language by 
> introducing an additional point of inconsistency.
> 
> Classes search the current namespace, but functions / const would search 
> namespace first, unless they don't, then global?

Assuming you mean "unless they don't" is the additional inconsistency:

I still see this as a cleaner/less verbose option than the currently available 
options
for avoiding ambiguity - aliases add similar resolution behavior.

"function_name() will search the current namespace first,
then the global namespace,
unless "use function [ as] function_name" was found
earlier in the namespace block."

> For the very minor one-time performance hit (thanks to the cache slot), 
> I think the situation is best remaining as-is for the time being.

That was unintuitive to me -- but it is one-time.
(ignoring optimizations of specialized opcodes
and inlining results as constants)
Running the following example outputs "Length is 4" twice.

 In future, I think the optimal solution is opt-in deprecating fallback 
> to the root namespace using a declare.
> ... Id like to see nikic/scalar_objects added to the core in 8.0

Various global functions (strlen(), count(), class_exists(), is_string(), etc.)
are more frequently used than namespaced functions in many files,
and removing the fallback *to* the global scope would break most third party 
code,
which might be unmaintained.
This backwards compatibility break would discourage upgrading
to future major versions.

> That doesn't cover defined constants, but IMO we should be pushing those 
> to be moved into class constants, simply because in the absense of 
> function / constant / anything-but-class level autoloading, things might 
> as well be in a readily available location.

Out of scope of this RFC: I had a thought today about autoloading.
I'd rather improve function / const autoloading instead of moving to classes. 
What if an ambiguous function_name() or const outside the global 
namespace would attempt to autoload *ambiguous* functions in the global scope,
but not the current namespace?
(and autoload unambiguous functions in their respective scope)
function_exists() or defined() would not autoload,
to preserve the behavior/performance of current programs.
Anything with the callable type hint (e.g. array_map) would also need to be 
modified.

- Same for global constants
- That should avoid the performance hit - this autoloading would only be 
triggered
  when php would previously throw an Error or warning
  for undefined functions/constants.
- This would also avoid the need to load polyfill files (e.g. mbstring)
  or test framework files when their functions/constants are unused.
- The main blocker for other autoload proposals
  seemed to be performance if I understood correctly
  (e.g. attempting to autoload NS\strlen() every time strlen was called)

Fully-qualified calls (through use, \, or being in the global scope) would
autoload the unambiguous name for missing functions.

And there'd have to be a hash map or other check
to avoid recursion on the same constant/function.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php