On Fri, Aug 2, 2024 at 7:03 PM Nick Lockheart wrote:
> I was thinking about a similar problem this week.
>
> If class A relies on class B, but you want to swap out
> class B with a stub to test class A in isolation,
> is there a way to make every call to class B,
> from class A, actually call a d
On 03.08.2024 at 00:00, Nick Lockheart wrote:
> I think some kind of sandboxing tools would be useful for
> build/test/deployment.
There are uopz[1] and runkit7[2] available on PECL which can be used to
unit-test untestable code (and more), but you are likely better off to
refactor such code soon
On Fri, 2024-08-02 at 21:37 +0100, Bilge wrote:
> Hi Ilija,
> I think this proposal has legs, and you are right to rekindle it,
> instead of letting it die quietly.
> On 02/08/2024 17:51, Ilija Tovilo wrote:
>
> > * Some mocking libraries (e.g. Symfony's ClockMock [5])
> > intentionally
> > decla
Hi Ilija,
I think this proposal has legs, and you are right to rekindle it,
instead of letting it die quietly.
On 02/08/2024 17:51, Ilija Tovilo wrote:
* Some mocking libraries (e.g. Symfony's ClockMock [5]) intentionally
declare functions called from some file in the files namespace to
inter
On Fri, 2024-08-02 at 18:53 +0100, Rowan Tommins [IMSoP] wrote:
> There was a proposal for exactly this a few years ago, which ended up
> in an RFC with a slightly different syntax (using a declare()
> statement), but was declined in voting by 35 votes to 2.
Sorry, I forgot the link: https://w
Hi,
I propose the following alternative approach:
* establish a restricted whitelist of global functions for which the
performance gain would be noteworthy if there wasn’t any need to look at local
scope first;
* for those functions, disallow to define a function of same name in any
namespace
On Fri, 2024-08-02 at 18:53 +0100, Rowan Tommins [IMSoP] wrote:
>
>
> On 2 August 2024 18:19:41 BST, Nick Lockheart
> wrote:
> > I had suggested a per-file directive in a post to this list a while
> > back. Something like:
> >
> > namespace foo;
> > use global functions;
>
> There was a propos
On 2 August 2024 18:19:41 BST, Nick Lockheart wrote:
>I had suggested a per-file directive in a post to this list a while
>back. Something like:
>
>namespace foo;
>use global functions;
There was a proposal for exactly this a few years ago, which ended up in an RFC
with a slightly different s
Hi,
Am 02.08.24 um 18:51 schrieb Ilija Tovilo:
...
There are a few noteworthy downsides:
* Unqualified calls to functions in the same namespace would be
slightly slower, because they now involve checking global scope first.
I believe that unqualified, global calls are much more common, so this
On Fri, 2024-08-02 at 18:51 +0200, Ilija Tovilo wrote:
> Hi everyone
>
> As you probably know, a common performance optimization in PHP is to
> prefix global function calls in namespaced code with a `\`. In
> namespaced code, relative function calls (meaning, not prefixed with
> `\`, not imported
On Fri, Aug 2, 2024, at 18:51, Ilija Tovilo wrote:
> It also
> sparked some related ideas, like providing modules that lock
> namespaces and optimize multiple files as a singular unit. That said,
> such approaches would likely be significantly more complex than the
> approach proposed here (~30 l
On Fri, Aug 2, 2024, at 18:51, Ilija Tovilo wrote:
> Hi everyone
>
> As you probably know, a common performance optimization in PHP is to
> prefix global function calls in namespaced code with a `\`. In
> namespaced code, relative function calls (meaning, not prefixed with
> `\`, not imported an
Hi everyone
As you probably know, a common performance optimization in PHP is to
prefix global function calls in namespaced code with a `\`. In
namespaced code, relative function calls (meaning, not prefixed with
`\`, not imported and not containing multiple namespace components)
will be looked up
Hi,
On Fri, Aug 2, 2024 at 1:36 PM Giovanni Giacobbi
wrote:
> It feels wrong to raise such an important requirement that might affect a
> lot of people, including maintainers of extensions
>
Why do you think that this might affect a lot of people? We are talking
about minimum GCC version 4.7 an
On Thu, 1 Aug 2024 at 23:57, Ilija Tovilo wrote:
> [...]
> I started fixing these in a PR [1] which required more changes than
> expected. After a short discourse, we were wondering whether it might
> be better to switch to a newer C standard instead. Our coding
> standards [2] currently specify
On Mon, 3 Jun 2024, Tim Düsterhus wrote:
> On 5/29/24 20:05, Derick Rethans wrote:
> >
> > For each op_array, Xdebug tries to figure out every possible path by
> > following jumps. Certain opcodes, such as GENERATOR_RETURN, THROW,
> > RETURN, and EXIT [1] are considered as an exit point out of t
On 2024-08-02 18:34, Mike Schinkel wrote:
On Jul 31, 2024, at 5:15 PM, Morgan wrote:
Also, providing a dedicated function for an algorithm over and above others
that don't get such special treatment inflates use of that algorithm, making it
more commonly used. It becomes self-reinforcing.
On 01.08.2024 at 23:57, Ilija Tovilo wrote:
> […] The biggest blocker in the past was MSVC, which has finally
> added C11 support in Visual Studio 2019 [8]. Technically, Visual
> Studio 2015 and 2017 are still supported by Microsoft [9], but
> according to Christoph they are no longer used for PHP
On 02.08.2024 at 07:50, Stephen Reay wrote:
> According to
> https://releases.llvm.org/3.1/docs/ClangReleaseNotes.html#cchanges, Clang 3.1
> added C11.
>
> According to https://trac.macports.org/wiki/XcodeVersionInfo, Clang 3.1
> shipped with Xcode 4.3.3, in May 2012.
>
> In terms of confirming
19 matches
Mail list logo
