On Sun, Jan 26, 2020 at 10:37 PM tyson andre <tysonandre...@hotmail.com>
wrote:
> > and that you have to explicitly say that you use the current namespace
> for that name:
> >
> > <?php
> > declare(function_and_const_lookup='global');
> > namespace MyNS;
> > use function MyNS\foo;
> > // or, equivalently: use function namespace\foo:
> >
> > function foo() { }
> >
> > foo(); // <-- this is the function defined just above
>
This would be a compile error right now though, because we don't allow
"use"d symbols and declarations to clash.
> That's a good solution to the ambiguity that I hadn't considered.
> Functions and constants should be relatively uncommon for most projects,
> although I can see it getting repetitive for a file with dozens of
> constants.
> (e.g. with namespace-scoped declares)
> define() or declare(function_and_const_lookup='global') should be adequate
> workarounds.
> - A subsequent RFC could reduce the restriction and make "const X = ..."
> always act as though it was immediately preceded by "use const X"
> This works better for constants than functions because constants can't
> be declared anywhere but the top level.
While I was the one who originally suggested to allow this kind of code, I
think it might be better to just unconditionally make it a compile error,
and require the use of declare(function_and_const_lookup='default') if you
want to declare namespaced constants or functions. The main motivation for
allowing it is interoperability with namespace-scoped declares, but as
those don't exist yet (and would still allow a per-file opt-out), we can
delay this issue.
I think that principally, the correct behavior here is to bring the symbol
into scope as it is declared, but as you already pointed out, this leads to
unclear semantics when conditional function declarations are involved.
As a minor note, rather than using 'default' as one of the values, I think
it would be better to use 'fallback' to make it robust against a potential
future change of defaults.
Regards,
Nikita
