On Wed, 29 Jan 2020 at 01:23, tyson andre wrote:
> If a future language change changed the *default* resolution rules for
> functions or constants,
> I'd rather have future maintainers make the decision on whether to add a
> 'fallback' to make migration
> than on whether to remove the 'fallback'
> > That's more of an objection to 'global' than an argument about 'fallback'
> > or 'default'.
> > It isn't suggesting a name to use instead of 'global'.
> >
>
>
> No, it's saying that whatever name you use, the guarantees of behaviour are
> only as strong or weak as decisions we make in the futur
On Tue, 28 Jan 2020 at 18:13, tyson andre wrote:
> That's more of an objection to 'global' than an argument about 'fallback'
> or 'default'.
> It isn't suggesting a name to use instead of 'global'.
>
No, it's saying that whatever name you use, the guarantees of behaviour are
only as strong or w
> What do you mean by "weaker"?
Any difference that might be expected by a user when for what differs
between leaving out the setting and setting it to 'fallback'/'default'.
E.g. in my example for `count`, a developer might expect `MyNs\count()`
to continue working as `MyNs\count()` when they se
On Tue, 28 Jan 2020 at 15:42, tyson andre wrote:
> > In other words, we don't need to know what the future modes are to know
> what modes we have *right now*, and give those modes names.
>
> If strict_types had a name instead of a number, we'd have a similar
> argument
> over whether there should
ant a change to the default mode in the engine
> to cause my code to be interpreted in a different way, so a 'default'
> option makes no sense to me.
I have a better understanding of why you're asking for this now,
but still prefer 'default' and 'global' for the reasons
> Le 28 janv. 2020 à 10:50, Nicolas Grekas a
> écrit :
>
> 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:
“Global” is the term used in the manual:
https://www.ph
On 28/01/2020 01:06, tyson andre wrote:
I don't plan to change the default name resolution behavior in PHP 9, though,
and if it does change, it might even be according to a different proposal,
so adding 'fallback' as a third option before we know what type of change is
planned
seems premature.
https://wiki.php.net/rfc/use_global_elements#implementation_details has been
updated after the latest feedback.
The implementation was also updated.
The opt-in `declare(function_and_const_lookup='global')` directive
now only allows declaring a function or constant in a file if the same name has
> Imagine this scenario:
>
> * PHP 8 introduces the declare with only 'global' and 'default' options
> allowed, as proposed.
> * PHP 9 makes 'default' a synonym for 'global', because it's now the
> default, and adds a new 'fallback' option
> * I have an application that uses the fallback mode
> I c
On 27/01/2020 14:43, tyson andre wrote:
I'd rather have that done when the future change of defaults is being proposed.
Supporting 'fallback' might cause confusion and extra work if the name
resolution defaults ever change in a different way.
At the point where they do change, we either do or do
On Mon, Jan 27, 2020 at 3:43 PM tyson andre
wrote:
> > This would be a compile error right now though, because we don't allow
> "use"d symbols and declarations to clash.
>
> As I surprisingly discovered when implementing the RFC, they don't clash.
> The PHP interpreter has a special case where it
> This would be a compile error right now though, because we don't allow "use"d
> symbols and declarations to clash.
As I surprisingly discovered when implementing the RFC, they don't clash.
The PHP interpreter has a special case where it doesn't warn or throw about the
name being in use
if the
On Sun, Jan 26, 2020 at 10:37 PM tyson andre
wrote:
> > and that you have to explicitly say that you use the current namespace
> for that name:
> >
> > > declare(function_and_const_lookup='global');
> > namespace MyNS;
> > use function MyNS\foo;
> > // or, equivalently: use function namespace\fo
> and that you have to explicitly say that you use the current namespace for
> that name:
>
> 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 d
Hi,
I object to the following proposed behaviour, which is confusing:
I think we can do better, following the example of what we have today, namely:
Currently, the following triggers a fatal error:
Therefore I suggest that the following be an error:
and that you have to explicitly say th
Hi,
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);
> Do you have plans to use the https://github.com/php/php-rfcs to promote the
> discussion as well, the same way
we did https://github.com/php/php-rfcs/pull/1 for the Typed Properties RFC?
No, I have no plans to switch to GitHub. At the time of writing,
https://github.com/php/php-rfcs/blob/maste
Hello Tyson,
On Wed, 1 Jan 2020 at 20:31, tyson andre wrote:
> Hi internals,
>
> 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://wik
19 matches
Mail list logo
