On Mon, Aug 5, 2024, at 20:49, Ilija Tovilo wrote:
> On Mon, Aug 5, 2024 at 3:33 PM Nick Lockheart wrote:
> >
> > This is a different problem that could be solved by a sandbox API.
>
> Not sure which case we were talking about then. ClockMock is what I've
> been referencing all along.
>
> > >
On Mon, Aug 5, 2024 at 3:33 PM Nick Lockheart wrote:
>
> This is a different problem that could be solved by a sandbox API.
Not sure which case we were talking about then. ClockMock is what I've
been referencing all along.
> > Well, ok. But then we're back to prefixing global calls, which
> > de
>
> Consider this example:
>
> namespace Foo;
> echo time();
>
> With my proposal, this would now always call the global time()
> function. You were suggesting that "using local functions" would help
> mitigate this, but I don't think it does.
>
> * The user can't add "using local functions" t
On Mon, Aug 5, 2024 at 2:27 PM Nick Lockheart wrote:
>
>
> > I'm not sure your proposal solves the mocking problem. If the engine
> > is to interpret all non-fq calls as global or local, how would a
> > library include your file while switching this configuration, when it
> > is implemented as som
> I'm not sure your proposal solves the mocking problem. If the engine
> is to interpret all non-fq calls as global or local, how would a
> library include your file while switching this configuration, when it
> is implemented as some directive in the file?
I'm not sure I understand this questio
On Mon, 2024-08-05 at 12:27 +0100, Derick Rethans wrote:
> On Sun, 4 Aug 2024, Nick Lockheart wrote:
>
> > 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
On Sun, 4 Aug 2024, Nick Lockheart wrote:
> 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 foun
On Mon, Aug 5, 2024 at 10:22 AM Nick Lockheart wrote:
>
> > Sorry, my language was not precise enough. Your proposal suggests
> > making unqualified calls global when the directive is present,
> > whereas my proposal suggests keeping local scope as a fallback, hence
> > the two not being compatibl
> >
> > I did not intend for all unqualified calls to become global, unless
> > the new directive is present.
>
> Sorry, my language was not precise enough. Your proposal suggests
> making unqualified calls global when the directive is present,
> whereas my proposal suggests keeping local scope
On Sun, Aug 4, 2024 at 8:41 PM Nick Lockheart wrote:
>
>
> >
> > But that's not quite what the RFC says:
> >
> > > 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
>
> But that's not quite what the RFC says:
>
> > 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, withou
> 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:
>
> >
> > “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 sh
On 04/08/2024 15:09, Nick Lockheart wrote:
> 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
Hi Nick
On Sun, Aug 4, 2024 at 7:29 PM Nick Lockheart wrote:
>
> So I wanted to get a "yes" from the people who need to say yes, then
> discuss all of those things you mentioned:
>
> 1. File level vs global
> 2. Syntax
> 3. Alternative options
>
> But I think we need a "yes" for the concept first
On Sun, 2024-08-04 at 19:15 +0200, Ilija Tovilo wrote:
> Hi Nick
>
> I find it a bit unfortunate that you gave my thread barely any time
> to
> be discussed.
>
My intent was to start a formal discussion on this very topic.
> This can be achieved in various ways. For example:
>
> * Per-file, v
Hi Nick
I find it a bit unfortunate that you gave my thread barely any time to
be discussed.
On Sun, Aug 4, 2024 at 1:42 PM Nick Lockheart wrote:
>
> 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 ye
Hey Nick,
On Sun, 4 Aug 2024 at 13:42, Nick Lockheart wrote:
> This also prevents the parser from using dedicated opcodes for built-in
> functions.
>
> This incurs a performance penalty.
>
For many, many years, tools like `doctrine/coding-standard` have imported
global functions.
The performanc
18 matches
Mail list logo
