> On 25 Aug 2024, at 06:09, Rowan Tommins [IMSoP] wrote:
>
> this is only a problem for option 1.
Fair point.
> the short/medium term impact is so big
Given the scope of it, I think realistically *any* change suggested here should
aim to target 9.0 for the deprecation (and 10 for the chang
>
> On Aug 23, 2024 at 2:30 PM, mailto:tovilo.il...@gmail.com)>
> wrote:
>
>
>
> On Fri, Aug 23, 2024 at 8:19 PM John Coggeshall
> wrote: > > 1. People who don't think BC is a problem, and would like to
> drop > either the global or local lookup ent
On Sun, Aug 25, 2024, at 00:58, Rowan Tommins [IMSoP] wrote:
>
>
> On 24 August 2024 19:16:13 BST, Stephen Reay wrote:
> >
> >> On 25 Aug 2024, at 00:01, Ilija Tovilo wrote::
> >>
> >> 1. Flipping lookup order: ~a few dozens of changes
> >> 2. Global only: ~3 000 changes
> >> 3. Local only:
On 24 August 2024 19:16:13 BST, Stephen Reay wrote:
>
>> On 25 Aug 2024, at 00:01, Ilija Tovilo wrote::
>>
>> 1. Flipping lookup order: ~a few dozens of changes
>> 2. Global only: ~3 000 changes
>> 3. Local only: ~139 000 changes
>There's also an impact on internals development/RFC with eith
On Sat, Aug 24, 2024, at 20:16, Stephen Reay wrote:
>
>
> > On 25 Aug 2024, at 00:01, Ilija Tovilo wrote:
> >
> > Hi Stephen
> >
> > On Sat, Aug 24, 2024 at 1:54 PM Stephen Reay
> > wrote:
> >>
> >> Thanks for clarifying. Out of curiosity, how much optimisation do you
> >> imagine would
On Sat, Aug 24, 2024, at 18:34, Ilija Tovilo wrote:
> Stephen
>
> On Sat, Aug 24, 2024 at 2:00 PM Stephen Reay wrote:
> >
> > When I said this thread reads like an April fools joke that wasn't a
> > challenge you know.
>
> We *just* had somebody temporarily banned for ad-hominem attacks like
> On 25 Aug 2024, at 00:01, Ilija Tovilo wrote:
>
> Hi Stephen
>
> On Sat, Aug 24, 2024 at 1:54 PM Stephen Reay wrote:
>>
>> Thanks for clarifying. Out of curiosity, how much optimisation do you
>> imagine would be possible if the lookups were done the same was as classes
>> (ie no fallba
> On 24 Aug 2024, at 23:34, Ilija Tovilo wrote:
>
> Stephen
>
> On Sat, Aug 24, 2024 at 2:00 PM Stephen Reay wrote:
>>
>> When I said this thread reads like an April fools joke that wasn't a
>> challenge you know.
>
> We *just* had somebody temporarily banned for ad-hominem attacks like
>
Hi Stephen
On Sat, Aug 24, 2024 at 1:54 PM Stephen Reay wrote:
>
> Thanks for clarifying. Out of curiosity, how much optimisation do you imagine
> would be possible if the lookups were done the same was as classes (ie no
> fallback, names must be local, qualified or imported with `use`)?
I hav
Stephen
On Sat, Aug 24, 2024 at 2:00 PM Stephen Reay wrote:
>
> When I said this thread reads like an April fools joke that wasn't a
> challenge you know.
We *just* had somebody temporarily banned for ad-hominem attacks like
a week ago. Please familiarize yourself with the mailing list rules.
T
On Sat, Aug 24, 2024, at 13:59, Stephen Reay wrote:
>
>
> > On 24 Aug 2024, at 16:24, Rob Landers wrote:
> >
> > In other words, if you want to autoload a global function, you need to call
> > it fully qualified.
>
> When I said this thread reads like an April fools joke that wasn't a
> ch
> On 24 Aug 2024, at 16:24, Rob Landers wrote:
>
> In other words, if you want to autoload a global function, you need to call
> it fully qualified.
When I said this thread reads like an April fools joke that wasn't a challenge
you know.
Are you seriously suggesting that unqualified funct
> On 24 Aug 2024, at 01:29, Ilija Tovilo wrote:
>
> The "hard to come by" part is referring to the engine, which is quite
> optimized for the current semantics. Some of PHPs quirky semantics
> make it hard to improve it further, this being one of them.
Thanks for clarifying. Out of curiosity
On Sat, Aug 24, 2024, at 11:00, Rob Landers wrote:
> On Fri, Aug 23, 2024, at 23:57, Ilija Tovilo wrote:
>> On Fri, Aug 23, 2024 at 9:41 PM Rowan Tommins [IMSoP]
>> wrote:
>> >
>> > On 23 August 2024 18:32:41 BST, Ilija Tovilo
>> > wrote:
>> > >IMO, 1. is too drastic. As people have mentioned,
On Fri, Aug 23, 2024, at 23:57, Ilija Tovilo wrote:
> On Fri, Aug 23, 2024 at 9:41 PM Rowan Tommins [IMSoP]
> wrote:
> >
> > On 23 August 2024 18:32:41 BST, Ilija Tovilo wrote:
> > >IMO, 1. is too drastic. As people have mentioned, there are tools to
> > >automate disambiguation. But unless we ga
On Fri, Aug 23, 2024 at 9:41 PM Rowan Tommins [IMSoP]
wrote:
>
> On 23 August 2024 18:32:41 BST, Ilija Tovilo wrote:
> >IMO, 1. is too drastic. As people have mentioned, there are tools to
> >automate disambiguation. But unless we gain some other benefit from
> >dropping the lookup entirely, why
On 23 August 2024 20:50:05 BST, Rob Landers wrote:
>If it were global only, then how would I call those files?
>namespace\read_and_process_file()?
See my earlier posts, particularly https://externals.io/message/124718#125098
and https://externals.io/message/124718#125125
Rowan Tommins
[IMSo
On Fri, Aug 23, 2024, at 21:41, Rowan Tommins [IMSoP] wrote:
>
>
> On 23 August 2024 18:32:41 BST, Ilija Tovilo wrote:
> >IMO, 1. is too drastic. As people have mentioned, there are tools to
> >automate disambiguation. But unless we gain some other benefit from
> >dropping the lookup entirely, w
On Aug 23 2024, at 3:41 pm, Rowan Tommins [IMSoP] wrote:
>
> None of these seem like showstoppers to me, but since we can so easily go one
> step further to "global only", and avoid them, why wouldn't we?
FWIW I'd support global only, specifically because of the point I wouldn't
necessarily w
On 23 August 2024 18:32:41 BST, Ilija Tovilo wrote:
>IMO, 1. is too drastic. As people have mentioned, there are tools to
>automate disambiguation. But unless we gain some other benefit from
>dropping the lookup entirely, why do it?
I can think of a few disadvantages of "global first":
- Fewe
> On 24 Aug 2024, at 01:37, John Coggeshall wrote:
>
>
>
> On Aug 23 2024, at 1:46 pm, Stephen Reay wrote:
>
>
> The claims about "security" because a function you defined (or included via a
> package) is resolved in place of a global one are irrelevant. If you're
> including compromised
On Aug 23 2024, at 1:46 pm, Stephen Reay wrote:
>
>
> The claims about "security" because a function you defined (or included via a
> package) is resolved in place of a global one are irrelevant. If you're
> including compromised code in your project, all bets are off.
I have plenty of experie
On Fri, Aug 23, 2024 at 8:19 PM John Coggeshall wrote:
>
> 1. People who don't think BC is a problem, and would like to drop
> either the global or local lookup entirely, requiring disambiguation.
>
> There is also an option of swapping the priority, making local lookups
> secondary to global loo
On Fri, Aug 23, 2024, at 19:32, Ilija Tovilo wrote:
> On Fri, Aug 23, 2024 at 5:49 PM Rowan Tommins [IMSoP]
> wrote:
> >
> > Other proposals aim to shift that balance - leaving some inconsistency, but
> > less compatibility break.
> >
> > And most users don't object to using a leading backslash
> 1. People who don't think BC is a problem, and would like to drop
> either the global or local lookup entirely, requiring disambiguation.
>
There is also an option of swapping the priority, making local lookups
secondary to global lookups -- and to override that behavior you would require
dis
On Fri, Aug 23, 2024 at 8:11 PM Stephen Reay wrote:
>
> On 24 Aug 2024, at 00:32, Ilija Tovilo wrote:
>
> > I obviously also disagree with 3. as I wouldn't have sent this
> > proposal otherwise. :) Performance improvements are hard to come by
> > nowadays. It was measured on real codebases (Symfo
> On 24 Aug 2024, at 00:32, Ilija Tovilo wrote:
>
> I obviously also disagree with 3. as I wouldn't have sent this
> proposal otherwise. :) Performance improvements are hard to come by
> nowadays. It was measured on real codebases (Symfony and Laravel).
Hi Ilija,
Just to make sure I'm not mis
> On 23 Aug 2024, at 23:56, John Coggeshall wrote:
>
>
>
> On Aug 23 2024, at 12:27 pm, Stephen Reay wrote:
>
> The current inconsistencies between symbol types can be avoided in userland
> in a 100% consistent way. Import or qualify the symbols you use, all the
> time, and you have 0 inco
On Fri, Aug 23, 2024 at 5:49 PM Rowan Tommins [IMSoP]
wrote:
>
> Other proposals aim to shift that balance - leaving some inconsistency, but
> less compatibility break.
>
> And most users don't object to using a leading backslash, they just (quite
> reasonably) have no idea what impact it has on
> What do you mean by this? What is "the right thing"?
Also, faster code vs. slower code by default is "the right thing" too.
On Aug 23 2024, at 12:35 pm, Stephen Reay wrote:
>
> > would find it non-sensical that you must add a backslash for the engine to
> > do the "right thing" (in this case, optimize their code with a security
> > benefit), vs just doing the right thing by default.
>
> What do you mean by this? Wh
On Aug 23 2024, at 12:27 pm, Stephen Reay wrote:
>
> The current inconsistencies between symbol types can be avoided in userland
> in a 100% consistent way. Import or qualify the symbols you use, all the
> time, and you have 0 inconsistencies or bizarreness in terms of what it used
> when.
S
> On 23 Aug 2024, at 23:13, John Coggeshall wrote:
>
>
>
> On Aug 23 2024, at 11:49 am, Rowan Tommins [IMSoP]
> wrote:
>
> And most users don't object to using a leading backslash, they just (quite
> reasonably) have no idea what impact it has on the ability of the engine to
> optimise t
> On 23 Aug 2024, at 22:49, Rowan Tommins [IMSoP] wrote:
>
>
>
> On 23 August 2024 15:04:32 BST, Stephen Reay wrote:
>>
>> I stand by the rest of my argument though. This entire ridiculous discussion
>> about a huge BC break that introduces bizarre inconsistencies, is 100%
>> because a h
On Aug 23 2024, at 11:49 am, Rowan Tommins [IMSoP] wrote:
>
> And most users don't object to using a leading backslash, they just (quite
> reasonably) have no idea what impact it has on the ability of the engine to
> optimise their code.
I think this is a misread, and I don't think you can ar
On 23 August 2024 15:04:32 BST, Stephen Reay wrote:
>
>I stand by the rest of my argument though. This entire ridiculous discussion
>about a huge BC break that introduces bizarre inconsistencies, is 100% because
>a handful of people don't want to type `\`.
Again, I'm not sure which straw man
> On 23 Aug 2024, at 20:20, Rowan Tommins [IMSoP] wrote:
>
> On Fri, 23 Aug 2024, at 13:43, Stephen Reay wrote:
>> This change would also break existing code that does "the right thing",
>> and has the potential to arbitrarily break perfectly valid userland
>> code *any time a new global fun
> On Aug 23, 2024, at 8:56 AM, Christian Schneider
> wrote:
>
> Am 23.08.2024 um 12:27 schrieb Rob Landers :
>> On Fri, Aug 23, 2024, at 12:14, Christian Schneider wrote:
>>> Am 23.08.2024 um 11:34 schrieb Nick Lockheart :
I think we are all trying to achieve the same thing here.
>>>
>>> I
> On Aug 23, 2024, at 9:07 AM, Rowan Tommins [IMSoP]
> wrote:
>
> On Fri, 23 Aug 2024, at 13:45, Mike Schinkel wrote:
>>> On Aug 23, 2024, at 8:33 AM, Rowan Tommins [IMSoP]
>>> wrote:
>>> On 23 August 2024 13:04:22 BST, Mike Schinkel wrote:
And how can it occur without an explicit `us
On Fri, 23 Aug 2024, at 13:43, Stephen Reay wrote:
> This change would also break existing code that does "the right thing",
> and has the potential to arbitrarily break perfectly valid userland
> code *any time a new global function is added*, forever.
You replied to me, but you seem to be com
> On 23 Aug 2024, at 15:08, Nick Lockheart wrote:
>
> A third option, which I haven't seen come up on the list yet, is that
> unqualified functions that are PHP built-ins are treated as global, and
> using a function having the same name as a built-in, in a namespace
> scope, requires a fully q
On Fri, Aug 23, 2024, at 14:56, Christian Schneider wrote:
> Am 23.08.2024 um 12:27 schrieb Rob Landers :
> > On Fri, Aug 23, 2024, at 12:14, Christian Schneider wrote:
> >> Am 23.08.2024 um 11:34 schrieb Nick Lockheart :
> >> > I think we are all trying to achieve the same thing here.
> >>
> >>
On Fri, 23 Aug 2024, at 13:45, Mike Schinkel wrote:
>> On Aug 23, 2024, at 8:33 AM, Rowan Tommins [IMSoP]
>> wrote:
>> On 23 August 2024 13:04:22 BST, Mike Schinkel wrote:
>>> And how can it occur without an explicit `use
>>> AcmeComponents\SplineReticulator\Utilities\Text\Text` statement, whic
Am 23.08.2024 um 12:27 schrieb Rob Landers :
> On Fri, Aug 23, 2024, at 12:14, Christian Schneider wrote:
>> Am 23.08.2024 um 11:34 schrieb Nick Lockheart :
>> > I think we are all trying to achieve the same thing here.
>>
>> I'm not sure who "we" and what "same thing" here exactly is.
>
> Nick w
> On Aug 23, 2024, at 8:33 AM, Rowan Tommins [IMSoP]
> wrote:
> On 23 August 2024 13:04:22 BST, Mike Schinkel wrote:
>> And how can it occur without an explicit `use
>> AcmeComponents\SplineReticulator\Utilities\Text\Text` statement, which I
>> proposed would override the automatic `use`, anyw
> On 23 Aug 2024, at 17:29, Rowan Tommins [IMSoP] wrote:
>
> On Fri, 23 Aug 2024, at 10:58, Stephen Reay wrote:
>> Making relative function names do the opposite of relative class names
>> sounds like a great way to permanently kill any prospects of
>> encouraging developers to use regular n
On 23 August 2024 13:04:22 BST, Mike Schinkel wrote:
>
>> It wouldn't be a top-level namespace that would cause a conflict, but a
>> nested one: currently the above code resolves the function name as
>> "AcmeComponents\SplineReticulator\Utilities\Text\Text\strlen" (note the
>> "...\Text\Text
On Fri, Aug 23, 2024, at 14:16, Rob Landers wrote:
> On Fri, Aug 23, 2024, at 11:27, Nick Lockheart wrote:
>> On Fri, 2024-08-23 at 09:16 +0100, Rowan Tommins [IMSoP] wrote:
>> >
>> >
>> > On 23 August 2024 01:42:38 BST, Nick Lockheart
>> > wrote:
>> > >
>> > > >
>> > > > BUT, if people alread
On Fri, Aug 23, 2024, at 11:27, Nick Lockheart wrote:
> On Fri, 2024-08-23 at 09:16 +0100, Rowan Tommins [IMSoP] wrote:
> >
> >
> > On 23 August 2024 01:42:38 BST, Nick Lockheart
> > wrote:
> > >
> > > >
> > > > BUT, if people already complain about "\" being ugly, having to
> > > > write
> >
On 23.08.2024 at 13:52, Mike Schinkel wrote:
> In theory it would be nice to open up PHP to allow overriding core functions,
> but that could also open a Pandora's box, the kind that makes Ruby code so
> fragile. At least in Go you have to omit the standard lib import and use your
> own import
> On Aug 23, 2024, at 7:50 AM, Rowan Tommins [IMSoP]
> wrote:
>
> On Fri, 23 Aug 2024, at 12:29, Mike Schinkel wrote:
>> namespace \AcmeComponents\SplineReticulator\Utilities\Text
>>
>> function Foo():int {
>> return Text\strlen("Hello World");
>> }
>>
>> The above of course could resu
> On Aug 23, 2024, at 4:08 AM, Nick Lockheart wrote:
> A third option, which I haven't seen come up on the list yet, is that
> unqualified functions that are PHP built-ins are treated as global, and
> using a function having the same name as a built-in, in a namespace
> scope, requires a fully qua
On Fri, 23 Aug 2024, at 12:29, Mike Schinkel wrote:
> namespace \AcmeComponents\SplineReticulator\Utilities\Text
>
> function Foo():int {
> return Text\strlen("Hello World");
> }
>
> The above of course could result in BC breaks IF there happened to be
> existing code that referenced Text\st
Hi Rowan,
> On Aug 23, 2024, at 2:39 AM, Rowan Tommins [IMSoP]
> wrote:
> On 23 August 2024 00:15:19 BST, Mike Schinkel wrote:
>> Having to prefix with a name like Foo, e.g. Foo\strlen() is FAR PREFERABLE
>> to _\strlen() because at least it provides satiating information rather than
>> the e
On Fri, 23 Aug 2024, at 10:58, Stephen Reay wrote:
> In a world where global functions take precedence over local ones
> because some people don't like writing a single \ character,
> autoloading would be a moot point because if you preference global
> functions you're implicitly telling develop
On Fri, 23 Aug 2024, at 10:58, Stephen Reay wrote:
> Making relative function names do the opposite of relative class names
> sounds like a great way to permanently kill any prospects of
> encouraging developers to use regular namespaced functions in place of
> static classes as "bag of function
On Fri, Aug 23, 2024, at 12:14, Christian Schneider wrote:
> Am 23.08.2024 um 11:34 schrieb Nick Lockheart :
> > I think we are all trying to achieve the same thing here.
>
> I'm not sure who "we" and what "same thing" here exactly is.
>
> I recall the following arguments for changing the current
On Fri, 23 Aug 2024, 11:02 Stephen Reay, wrote:
>
>
> > On 23 Aug 2024, at 15:29, Rowan Tommins [IMSoP]
> wrote:
> >
> > having global as the default mode (even if we provide an option for
> local) is much less disruptive to existing code.
>
> Hi Rowan,
>
> I don't disagree with this summary of
Am 23.08.2024 um 11:34 schrieb Nick Lockheart :
> I think we are all trying to achieve the same thing here.
I'm not sure who "we" and what "same thing" here exactly is.
I recall the following arguments for changing the current situation about
function look ups:
- Performance
- Function autoloadi
> On 23 Aug 2024, at 15:29, Rowan Tommins [IMSoP] wrote:
>
> having global as the default mode (even if we provide an option for local) is
> much less disruptive to existing code.
Hi Rowan,
I don't disagree with this summary of the current state, but I think this
misses an important factor
> >
> >
> > A third option, which I haven't seen come up on the list yet, is
> > that
> > unqualified functions that are PHP built-ins are treated as global,
> > and
> > using a function having the same name as a built-in, in a namespace
> > scope, requires a fully qualified name to override the
On Fri, 2024-08-23 at 09:16 +0100, Rowan Tommins [IMSoP] wrote:
>
>
> On 23 August 2024 01:42:38 BST, Nick Lockheart
> wrote:
> >
> > >
> > > BUT, if people already complain about "\" being ugly, having to
> > > write
> > > "namespace\" is going to make them REALLY grumpy...
> > > So maybe at
On Fri, Aug 23, 2024, at 10:08, Nick Lockheart wrote:
>
> >
> > If we were to go with any major change in the current lookup where it
> > is perf or nothing, this is what I would propose for php 9.0
> > (starting with an immediate deprecation):
> >1. any unqualified call simply calls the curr
On Fri, 23 Aug 2024, at 08:27, Nick Lockheart wrote:
> Could be mistaken, but I think the way PHP handles namespaces
> internally is sort of the same as a long string, rather than as a
> tree/hierarchy.
Just to be clear, PHP already has a syntax for explicitly resolving a name
relative to the cur
On 23 August 2024 01:42:38 BST, Nick Lockheart wrote:
>
>>
>> BUT, if people already complain about "\" being ugly, having to write
>> "namespace\" is going to make them REALLY grumpy...
>> So maybe at the same time (or, probably, in advance) we need to come
>> up with a nicer syntax for expli
>
> If we were to go with any major change in the current lookup where it
> is perf or nothing, this is what I would propose for php 9.0
> (starting with an immediate deprecation):
> 1. any unqualified call simply calls the current namespace
> 2. >= php 9.0: no fallback to global
> 3. <
On Fri, Aug 23, 2024, at 09:27, Nick Lockheart wrote:
> On Fri, 2024-08-23 at 07:39 +0100, Rowan Tommins [IMSoP] wrote:
> >
> >
> > On 23 August 2024 00:15:19 BST, Mike Schinkel
> > wrote:
> > > Having to prefix with a name like Foo, e.g. Foo\strlen() is FAR
> > > PREFERABLE to _\strlen() becaus
On Fri, 2024-08-23 at 07:39 +0100, Rowan Tommins [IMSoP] wrote:
>
>
> On 23 August 2024 00:15:19 BST, Mike Schinkel
> wrote:
> > Having to prefix with a name like Foo, e.g. Foo\strlen() is FAR
> > PREFERABLE to _\strlen() because at least it provides satiating
> > information rather than the emp
On 23 August 2024 00:15:19 BST, Mike Schinkel wrote:
>Having to prefix with a name like Foo, e.g. Foo\strlen() is FAR PREFERABLE to
>_\strlen() because at least it provides satiating information rather than the
>empty calories of a cryptic shorthand. #jmtcw, anyway.
I knew I'd regret keepin
>
> BUT, if people already complain about "\" being ugly, having to write
> "namespace\" is going to make them REALLY grumpy...
> So maybe at the same time (or, probably, in advance) we need to come
> up with a nicer syntax for explicitly referencing the current
> namespace.
> Unfortunately, fin
> On Aug 22, 2024, at 5:32 PM, Rowan Tommins [IMSoP]
> wrote:
> I was thinking about this earlier, and how the migration is pretty much the
> same (and equally automatable) in either direction:
>
> * If unqualified calls become always local, then every global function call
> needs a use statem
On 02/08/2024 23:00, Nick Lockheart wrote:
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 different class
during the test, without modifying class A's code?
The
On 04/08/2024 18:41, Ilija Tovilo wrote:
* Prefix your calls with namespace\. That's quite ugly, but is the
syntax we currently offer.
I was thinking about this earlier, and how the migration is pretty much
the same (and equally automatable) in either direction:
* If unqualified calls becom
On Aug 22 2024, at 4:09 am, Rob Landers wrote:
>
> If you have the ability to inject arbitrary code, you've already lost. It
> doesn't matter whether they use this feature, or just register a shutdown
> function, autoloader, replace classes/functions/methods entirely, or
> whatever. Should we
On Wed, Aug 21, 2024, at 20:32, John Coggeshall wrote:
>
>
> On Aug 21 2024, at 2:10 pm, Ilija Tovilo wrote:
>>
>> Including a malicious composer package already allows for arbitrary
>> code execution, do you really need more than that?
>
> Of course. We've seen many examples in the wild of 3r
Forgive me, s/Illija/you :)
On Aug 21 2024, at 2:10 pm, Ilija Tovilo wrote:
>
> Including a malicious composer package already allows for arbitrary
> code execution, do you really need more than that?
>
Of course. We've seen many examples in the wild of 3rd party libraries getting
hijacked to inject malicious code (e.g.
Hi John
On Wed, Aug 21, 2024 at 8:02 PM John Coggeshall wrote:
>
> This is an attack vector for every application and I would argue should be a
> real concern for the vast majority of applications out there -- any which
> rely on namespace-based frameworks and composer packages from untrustwor
On Aug 21 2024, at 8:03 am, Rob Landers wrote:
>
> If this is an attack vector for your application, then fully qualified names
> is the way to go (WordPress does this nearly everywhere, for example).
This is an attack vector for every application and I would argue should be a
real concern for
On Wed, Aug 21, 2024, at 10:23, John Coggeshall wrote:
>
>
> On Aug 2 2024, at 4:37 pm, Bilge wrote:
>> My only concern is there needs to be an alternative way to do this:
>> intercepting internal calls. Sometimes, whether due to poor architecture or
>> otherwise, we just need to be able to
Am 21.08.2024 um 09:44 schrieb Faizan Akram Dar :
> On Wed, Aug 21, 2024, 9:34 AM Christian Schneider
> wrote:
>> The point where I think we disagree is that it improves the code. It may
>> improve performance of the code (even though I somewhat doubt this has a
>> *significant* impact on most
On Aug 2 2024, at 4:37 pm, Bilge wrote:
> My only concern is there needs to be an alternative way to do this:
> intercepting internal calls. Sometimes, whether due to poor architecture or
> otherwise, we just need to be able to replace an internal function call. One
> example I can think of r
On Wed, Aug 21, 2024, 9:34 AM Christian Schneider
wrote:
> Am 20.08.2024 um 17:14 schrieb Levi Morrison >:
> > Keep in mind that qualifying
> > every global function is annoying but probably can be somewhat
> > automated, and will bring better performance. So again, this improves
> > the existin
On Tue, Aug 20, 2024 at 8:26 PM Christian Schneider
wrote:
>
> Am 20.08.2024 um 17:14 schrieb Levi Morrison :
> > Keep in mind that qualifying
> > every global function is annoying but probably can be somewhat
> > automated, and will bring better performance. So again, this improves
> > the existi
Am 20.08.2024 um 17:14 schrieb Levi Morrison :
> Keep in mind that qualifying
> every global function is annoying but probably can be somewhat
> automated, and will bring better performance. So again, this improves
> the existing code even without upgrading.
Just to be sure: Would code *not* using
On Tue, Aug 20, 2024, at 23:56, Faizan Akram Dar wrote:
>
>
> On Tue, Aug 20, 2024 at 11:34 PM Ilija Tovilo wrote:
>> Hi Levi
>>
>> On Tue, Aug 20, 2024 at 5:14 PM Levi Morrison
>> wrote:
>> >
>> > I have long been in favor of a larger BC break with better language
>> > consistency. Class look
On Tue, Aug 20, 2024 at 11:34 PM Ilija Tovilo
wrote:
> Hi Levi
>
> On Tue, Aug 20, 2024 at 5:14 PM Levi Morrison
> wrote:
> >
> > I have long been in favor of a larger BC break with better language
> > consistency. Class lookup and function lookup with respect to
> > namespaces should be treated
Hi Levi
On Tue, Aug 20, 2024 at 5:14 PM Levi Morrison
wrote:
>
> I have long been in favor of a larger BC break with better language
> consistency. Class lookup and function lookup with respect to
> namespaces should be treated the same. The difficulty is getting a
> majority of people to vote ye
> To sum up, I think we need to remove the fallback behavior, so we can have
> better things in the future.
> Either keep only local with a bigger BC break but a better language
> consistency.
> Or keep only global with a smaller BC break.
I have long been in favor of a larger BC break with bett
On Tue, Aug 20, 2024, at 10:41, Nick Lockheart wrote:
>
> > We would upgrade that to a warning in PHP 9.2, and it would end up
> > being an error on PHP 10 and have a BC break.
> >
> > I don't think adding a \ to each function call is ugly, that's what
> > we have for classes, and it works fine
> We would upgrade that to a warning in PHP 9.2, and it would end up
> being an error on PHP 10 and have a BC break.
>
> I don't think adding a \ to each function call is ugly, that's what
> we have for classes, and it works fine; or an use statement.
>
> So, why do we think that after people g
On Sun, Aug 4, 2024 at 8:43 PM Ilija Tovilo wrote:
> Hi Rob
>
> On Fri, Aug 2, 2024 at 7:10 PM Rob Landers wrote:
> >
> > So, what you’re saying is that symfony and laravel can get a performance
> increase by simply adding a \ in the right places? Why don’t they do that
> instead of changing the
On Mon, Aug 5, 2024 at 1:23 PM Derick Rethans wrote:
>
> On Fri, 2 Aug 2024, Ilija Tovilo wrote:
>
> > As for providing a migration path: One approach might be to introduce
> > an INI setting that performs the function lookup in both local and
> > global scope at run-time, and informs the user abo
On Fri, 2 Aug 2024, Ilija Tovilo wrote:
> As for providing a migration path: One approach might be to introduce
> an INI setting that performs the function lookup in both local and
> global scope at run-time, and informs the user about the behavioral
> change in the future.
That INI setting wo
On Sun, 2024-08-04 at 19:53 +0200, Ilija Tovilo wrote:
> Hi Claude
>
> On Fri, Aug 2, 2024 at 9:02 PM Claude Pache
> wrote:
> >
> > I propose the following alternative approach:
> >
> > * establish a restricted whitelist of global functions for which
> > the performance gain would be noteworthy
Hi Claude
On Fri, Aug 2, 2024 at 9:02 PM Claude Pache wrote:
>
> 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
Hi Rob
On Fri, Aug 2, 2024 at 7:10 PM Rob Landers wrote:
>
> So, what you’re saying is that symfony and laravel can get a performance
> increase by simply adding a \ in the right places? Why don’t they do that
> instead of changing the language?
Nothing, of course. However, a Symfony maintaine
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
1 - 100 of 110 matches
Mail list logo
