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 Fri, Aug 23, 2024, at 23:06, Larry Garfield wrote:
> On Fri, Aug 23, 2024, at 1:38 PM, Rob Landers wrote:
> > On Fri, Aug 23, 2024, at 20:27, Bruce Weirdan wrote:
> >> On Fri, Aug 23, 2024 at 4:27 PM Larry Garfield
> >> wrote:
> >>> Moving those definitions to attributes is certainly possible,
On Fri, Aug 23, 2024 at 4:31 PM Larry Garfield wrote:
>
> The null option is always an option, yes. The thing to understand is that
> today, *we already have erased generics*, via PHPStan/Psalm. That's one
> reason I am, personally, against erased generics in the language proper.
> They don'
On Fri, Aug 23, 2024, at 23:10, Vincent Langlet wrote:
> I found a simpler implementation later which rely on array_keys
> ```
> fn is_int_string(string $s): bool => \is_int(array_keys([$s => null])[0]);
> ```
>
> I considered that `is_int_string` was better in the same namespace than
> `is_obje
I found a simpler implementation later which rely on array_keys
```
fn is_int_string(string $s): bool => \is_int(array_keys([$s => null])[0]);
```
I considered that `is_int_string` was better in the same namespace than
`is_object`, `is_array`, `is_int`, `is_numeric`, ... but maybe there was
someth
On Fri, Aug 23, 2024, at 1:38 PM, Rob Landers wrote:
> On Fri, Aug 23, 2024, at 20:27, Bruce Weirdan wrote:
>> On Fri, Aug 23, 2024 at 4:27 PM Larry Garfield
>> wrote:
>>> Moving those definitions to attributes is certainly possible, though AFAIK
>>> both the PHPStan and Psalm devs have expresse
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 Mon, Aug 19, 2024, at 19:08, Derick Rethans wrote:
> Hi!
>
> Arnaud, Larry, and I have been working on an article describing the
> state of generics and collections, and related "experiments".
>
> You can find this article on the PHP Foundation's Blog:
> https://thephp.foundation/blog/2024/08
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 Fri, Aug 23, 2024, at 20:27, Bruce Weirdan wrote:
> On Fri, Aug 23, 2024 at 4:27 PM Larry Garfield wrote:
>> Moving those definitions to attributes is certainly possible, though AFAIK
>> both the PHPStan and Psalm devs have expressed zero interest in it.
>> Part of the challenge is that such
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 4:27 PM Larry Garfield
wrote:
> Moving those definitions to attributes is certainly possible, though AFAIK
> both the PHPStan and Psalm devs have expressed zero interest in it.
>
Part of the challenge is that such an approach will either still involve
> string parsing,
T
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 Fri, Aug 23, 2024, at 6:48 AM, Roman Pronskiy wrote:
> On Mon, Aug 19, 2024 at 7:11 PM Derick Rethans wrote:
>>
>> Arnaud, Larry, and I have been working on an article describing the
>> state of generics and collections, and related "experiments".
>>
>> You can find this article on the PHP Foun
On Fri, Aug 23, 2024, at 4:58 AM, Kévin Dunglas wrote:
> Thanks for sharing this research work.
>
> Instead of having to choose between fully reified generics and erased
> type declarations, couldn't we have both? A new option in php.ini could
> allow to enable the “erased” mode as a performance,
> 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 Fri, Aug 23, 2024, at 15:05, Bilge wrote:
> On 23/08/2024 11:34, Derick Rethans wrote:
>> On Wed, 10 Jul 2024, Derick Rethans wrote:
>>
>>
>>> We discussed this during one of our foundation meetings, and we propose:
>>>
>>> - to delete all notes with a rating less than -5 that are older tha
> 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
On 23/08/2024 11:34, Derick Rethans wrote:
On Wed, 10 Jul 2024, Derick Rethans wrote:
We discussed this during one of our foundation meetings, and we propose:
- to delete all notes with a rating less than -5 that are older than a
year.
As general consensus was that this correct, I will be
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 Fri, Aug 23, 2024 at 8:51 AM Roman Pronskiy
wrote:
>
> Do you consider the path of not adding generics to the core at all? In
> fact, this path is implicitly taken during the last years. So maybe it
> makes sense to enforce that status quo?
>
> Potential steps:
> - Make the current status quo
> 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
On Mon, Aug 19, 2024 at 7:11 PM Derick Rethans wrote:
>
> Arnaud, Larry, and I have been working on an article describing the
> state of generics and collections, and related "experiments".
>
> You can find this article on the PHP Foundation's Blog:
> https://thephp.foundation/blog/2024/08/19/stat
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 Wed, 10 Jul 2024, Derick Rethans wrote:
> We discussed this during one of our foundation meetings, and we propose:
>
> - to delete all notes with a rating less than -5 that are older than a
> year.
As general consensus was that this correct, I will be creating a script
for this.
One of t
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
Thanks for sharing this research work.
Instead of having to choose between fully reified generics and erased type
declarations, couldn't we have both? A new option in php.ini could allow to
enable the “erased” mode as a performance, production-oriented optimization.
In development, and on projects
> 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
70 matches
Mail list logo
