> On 20. May 2019, at 22:30, Theodore Brown wrote:
>
> On Mon, May 20, 2019 at 2:36 PM Gabriel O wrote:
>>
>> Yes, this is misconception. Namespace resolutions are cached. First
>> fixer tool bringing support for this was correct: PHP-CS-Fixer auto
>> imports only optimized functions for this
On Mon, 20 May 2019 at 20:01, M. W. Moe wrote:
>
> *abusive stuff that shouldn't be on this list*
Please don't troll.
You might be aiming for being amusing, but you're just being disruptive.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://w
On Mon, May 20, 2019 at 2:36 PM Gabriel O wrote:
> > Can you clarify? I'm not sure what performance improvement trick you
> > are referring to, or what you mean by "importing all functions". Are
> > you saying it's a misconception that triggering an autoloader on
> > unqualified function calls in
On 20. May 2019, at 20:42, Theodore Brown wrote:
>
> Can you clarify? I'm not sure what performance improvement trick you
> are referring to, or what you mean by "importing all functions". Are
> you saying it's a misconception that triggering an autoloader on
> unqualified function calls in a nam
On Mon, May 20, 2019 at 12:56 PM Marco Pivetta wrote:
> I do like the approach, as it makes the (better) fallback-less function
> usage opt-in, which is currently only fixed by coding-standards tooling.
> To be clear, would this lead to a "Fatal error: Uncaught Error: Call
> to undefined functio
On 5/20/19 8:45 PM, Marco Pivetta wrote:
Disabling function mocking is good ©️
It was a terrible practice in first place, and it is usually done for
impure functions that should be wrapped in integration-tested adapters.
Hear, hear :)
--
PHP Internals - PHP Runtime Development Mailing List
To
Hello,
"Disabling function mocking is good", in my life I read many idioties; this
one gets the "Palme d'Or";
This majesty; crowned Emperor.
On Mon, May 20, 2019 at 11:45 AM Marco Pivetta wrote:
> On Mon, 20 May 2019, 20:01 Gabriel O, wrote:
>
> >
> > On 20 May 2019 7:17:58 PM Theodore Brown
On Mon, 20 May 2019, 20:01 Gabriel O, wrote:
>
> On 20 May 2019 7:17:58 PM Theodore Brown wrote:
>
> > Every time function autoloading been brought up in the past, there
> > have been concerns about performance issues when calling a global
> > function from inside a namespace. E.g. calling `strl
On Mon, May 20, 2019 at 1:00 PM Gabriel O wrote:
> > Every time function autoloading been brought up in the past, there
> > have been concerns about performance issues when calling a global
> > function from inside a namespace. E.g. calling `strlen` in a loop
> > would become far slower if every
On 20 May 2019 7:17:58 PM Theodore Brown wrote:
Every time function autoloading been brought up in the past, there
have been concerns about performance issues when calling a global
function from inside a namespace. E.g. calling `strlen` in a loop
would become far slower if every call has to t
Hey Theodore,
On Mon, May 20, 2019 at 7:17 PM Theodore Brown
wrote:
> Every time function autoloading been brought up in the past, there
> have been concerns about performance issues when calling a global
> function from inside a namespace. E.g. calling `strlen` in a loop
> would become far slow
Every time function autoloading been brought up in the past, there
have been concerns about performance issues when calling a global
function from inside a namespace. E.g. calling `strlen` in a loop
would become far slower if every call has to trigger the autoloader.
But isn't it extremely rare to
12 matches
Mail list logo
