> 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 feedbac
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
> 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
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 w
> 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
h
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
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 m
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
> 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
> > 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 cla
> 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.
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_am
> 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
"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
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
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.
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_am
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_g
> 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/
> 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 wou
> 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
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 au
> 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
23 matches
Mail list logo
