Re: [PHP-DEV] function autoloading v4 RFC

> On 15 Aug 2024, at 22:22, Rob Landers wrote: > > Hello internals, > > I've decided to attempt an RFC for function autoloading. After reading > hundreds of ancient (and recent) emails relating to the topic along with > several abandoned RFCs from the past, and after much review, I've decide

Re: [PHP-DEV] function autoloading v4 RFC

Sent from my iPhone > On 16 Aug 2024, at 04:45, Rob Landers wrote: > > Userland functions don't throw that error, so it shouldn't be an issue. (You > can pass as many arguments as you want to a userland function, as long as > there are enough of them). Hi Rob, I didn't mean the actual inte

Re: [PHP-DEV] function autoloading v4 RFC

Hi Rob, > On 18 Aug 2024, at 04:33, Rob Landers wrote: > > I wouldn't consider it a BC break, no. But (ironically?), Symfony crashes > with this change. I wasn't aware of that specific code before but it's exactly the type of issue I was talking about earlier. > Ah, good catch. I've update

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

> 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

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

> 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 >> encouragin

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

> 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

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

> 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

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

> 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 incon

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

> 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

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

> 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

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

> 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

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

> 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 a

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

> 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

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

> 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

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

> 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 te

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

> 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 t

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

> 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

Re: [PHP-DEV] [RFC] Default expression

> On 24 Aug 2024, at 23:49, Bilge wrote: > > Hi gang, > > New RFC just dropped: https://wiki.php.net/rfc/default_expression. I think > some of you might enjoy this one. Hit me with any feedback. > > This one already comes complete with working implementation that I've been > cooking for a l

Re: [PHP-DEV] Declaration-aware attributes

> On 30 May 2023, at 07:48, Andreas Hennings wrote: > > Hello internals, > I am picking up an idea that was mentioned by Benjamin Eberlei in the past. > https://externals.io/message/110217#110395 > (we probably had the idea independently, but Benjamin's is the first > post where I see it menti

Re: [PHP-DEV] Declaration-aware attributes

(Resending to the list without all the history because qmail complained about message size) >> >> Hi Andreas, >> >> I too have wondered (and I think asked in room11?) about such a concept. >> >From memory the general response was “just do it in userland with a >> wrapper” so its good to see

Re: [PHP-DEV] [RFC] [Discussion] Clone with

Sent from my iPhone > On 9 Jun 2023, at 02:33, Larry Garfield wrote: > > On Thu, Jun 8, 2023, at 6:15 PM, Nicolas Grekas wrote: >>> On Tue, May 30, 2023, at 10:04 PM, Alexandru Pătrănescu wrote: > On Tue, May 30, 2023, 19:39 Larry Garfield wrote: > >>> On Mon, May 29, 2023

Re: [PHP-DEV] [RFC] [Discussion] Clone with

> On 9 Jun 2023, at 07:11, Larry Garfield wrote: > > On Thu, Jun 8, 2023, at 5:39 PM, Stephen Reay wrote: > >> Is there a specific reason `clone with (foo: $bar);` can’t simply pass >> the arguments given to with(), to the __clone() magic method? >> >>

Re: [PHP-DEV] RFC [Discussion]: Closure self-reference

> On 4 Jun 2023, at 02:11, Dan Ackroyd wrote: > > Hi internals, > > I'm now opening the discussion for the Closure self-reference RFC: > https://wiki.php.net/rfc/closure_self_reference > > This was previously discussed as a draft here: > https://externals.io/message/112216#112216 > > Thank-

Re: [PHP-DEV] [RFC] [Discussion] Clone with

> On 9 Jun 2023, at 20:55, Larry Garfield wrote: > > On Fri, Jun 9, 2023, at 5:34 AM, Stephen Reay wrote: > >> If the property hooks RFC had already passed a vote, I’d suggest that >> some expansion of hooks could provide a cleaner solution here, but it >> has

Re: [PHP-DEV] RFC1867 (multipart/form-data) PUT requests

> On 28 Jun 2023, at 02:53, Ben Ramsey wrote: > >> On Jun 27, 2023, at 04:01, Ilija Tovilo wrote: >> >> Hi Ben, Hi Rowan >> >> On Mon, Jun 26, 2023 at 8:55 PM Ben Ramsey wrote: >>> On Jun 20, 2023, at 06:06, Rowan Tommins wrote: On Tue, 20 Jun 2023 at 10:25, Ilija Tovilo

Re: [PHP-DEV] [RFC] [Discussion] DOM HTML5 parsing and serialization support

> On 17 Sep 2023, at 18:28, Niels Dossche wrote: > > Hi Alexandru > > On 9/17/23 11:59, Alexandru Pătrănescu wrote: >> On Sat, Sep 16, 2023, 02:17 Niels Dossche wrote: >> >>> >>> We'll add a common abstract base class DOM\Document (name taken from the >>> DOM spec & Javascript world). >>> D

Re: [PHP-DEV] [RFC] [Discussion] DOM HTML5 parsing and serialization support

> On 19 Sep 2023, at 01:00, Niels Dossche > > Cheers > Niels > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php (Resending with history removed due to apparent size limit) Hi Niels, Obviously, a method with different sign

Re: [PHP-DEV] [RFC] [Discussion] DOM HTML5 parsing and serialization support

> On 19 Sep 2023, at 14:30, Tim Düsterhus wrote: > > Hi > > On 9/19/23 08:35, Stephen Reay wrote: >> Regarding the private constructor: I understand the issue with the *old* >> class being confusing - but your new class doesn't have that issue, because >&

Re: [PHP-DEV] [RFC] [Discussion] DOM HTML5 parsing and serialization support

> On 20 Sep 2023, at 03:03, Niels Dossche wrote: > > Hi Stephen > > On 19/09/2023 09:58, Stephen Reay wrote: >> >> >>> On 19 Sep 2023, at 14:30, Tim Düsterhus wrote: >>> >>> Hi >>> >>> On 9/19/23 08:35, Stephen Re

Re: [PHP-DEV] RFC Proposal - static modifier for classes

> On 21 Nov 2023, at 06:48, Mike Schinkel wrote: > > Wow. > Hi, (This is not a direct reply to Mike, his just seems to be less shouty than other recent emails) I'm not *particularly* bothered by the results of this specific RFC either way - a *similar enough* result is already possible

Re: [PHP-DEV] RFC Proposal - static modifier for classes

> On 23 Nov 2023, at 17:21, Rowan Tommins wrote: > > On Thu, 23 Nov 2023 at 06:00, Stephen Reay wrote: > >> I'm disappointed to see yet again that there's this implied notion that >> working with PHP in 2023 means "well surely you must be using com

Re: [PHP-DEV] RFC Proposal - static modifier for classes

> On 23 Nov 2023, at 19:42, Rowan Tommins wrote: > > On Thu, 23 Nov 2023 at 11:48, Stephen Reay wrote: > >> >> Respectively, I disagree that it's "not a big problem" if your goal is to >> encourage people to use regular functions over classe

Re: [PHP-DEV] RFC Proposal - static modifier for classes

> On 24 Nov 2023, at 01:09, Rowan Tommins wrote: > > On Thu, 23 Nov 2023 at 14:20, Stephen Reay wrote: > >> >> Out of the box, with no package manager or module loader or anything, you >> can do as little as call `spl_autoload_register` with no argume

Re: [PHP-DEV] What is the prevailing sentiment about extract() and compact() ?

> On 29 Nov 2023, at 09:58, Larry Garfield wrote: > > On Tue, Nov 28, 2023, at 7:49 PM, Juliette Reinders Folmer wrote: >> L.S., >> >> What with all the drives towards cleaner code, how do people feel >> nowadays about `extract()` and `compact()` still being supported ? >> >> Both have alter

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

> On 7 Dec 2023, at 13:36, Alex Pravdin wrote: > > Hello internals, > > > This is the second round of the discussion regarding arbitrary precision > scalar type integration into PHP. The previous part: > https://marc.info/?l=php-internals&m=168250492216838&w=2 was initiated by me > before

Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2

> On 23 Feb 2024, at 06:56, Larry Garfield wrote: > > On Wed, Feb 21, 2024, at 11:02 PM, Matthew Weier O'Phinney wrote: >> On Wed, Feb 21, 2024 at 12:57 PM Larry Garfield >> wrote: >>> After much on-again/off-again work, Ilija and I are back with a more >>> polished property access hooks/int

Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2

 > On 23 Feb 2024, at 22:58, Larry Garfield wrote: > > On Fri, Feb 23, 2024, at 8:33 AM, Stephen Reay wrote: >>> On 23 Feb 2024, at 06:56, Larry Garfield wrote: > >> Hi Larry, >> It's good to see this idea still progressing. >> I have to agree

Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2

> On 28 Feb 2024, at 06:17, Larry Garfield wrote: > > On Sun, Feb 25, 2024, at 10:16 PM, Rowan Tommins [IMSoP] wrote: >> [Including my full previous reply, since the list and gmail currently >> aren't being friends. Apologies that this leads to rather a lot of >> reading in one go...] > > E

Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2

> On 28 Feb 2024, at 21:25, Larry Garfield wrote: > > On Wed, Feb 28, 2024, at 7:49 AM, Stephen Reay wrote: > > *snip* > >>> == Re virtual properties: >>> >>> Ilija and I talked this through, and there's pros and cons to a `virtual` >

Re: [PHP-DEV] Idea: Implicit inheriting function argument & return type-hint

> On 9 Mar 2024, at 21:27, Christian Schneider wrote: > Am 09.03.2024 um 08:18 schrieb Marc : >> As the pseudo type `mixed` exists since PHP 8.0, which is already >> out-of-date, I have the feeling it would be better to force people to >> explicitly write `mixed` to widen the type of an over

Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2

> On 8 Mar 2024, at 22:53, Larry Garfield wrote: > > Hi folks. Based on earlier discussions, we've made a number of changes to > the RFC that should address some of the concerns people raised. We also had > some very fruitful discussions off-list with several developers from the > Foundat

Re: [PHP-DEV] PDO subclass names

Sent from my iPhoneOn 23 Apr 2024, at 18:21, Lynn wrote:On Tue, Apr 23, 2024 at 10:21 AM Bilge wrote:On 21/04/2024 14:00, Saki Takamachi wrote: > Hi internals, > > Recently I've been working on an RFC regarding object support for BCMath. While working on that, I learned o

Re: [PHP-DEV] PDO subclass names

Sent from my iPhoneOn 23 Apr 2024, at 19:26, Lynn wrote:On Tue, Apr 23, 2024 at 11:26 AM Stephen Reay <php-li...@koalephant.com> wrote:Sent from my iPhoneOn 23 Apr 2024, at 18:21, Lynn <kja...@gmail.com> wrote:On Tue, Apr 23, 2024 at 10:21 AM Bilge <bi...@scriptfusion.com> w

Re: [PHP-DEV] PDO subclass names

Sent from my iPhone > On 23 Apr 2024, at 22:35, Bilge wrote: > On 23/04/2024 10:25, Stephen Reay wrote: >> The argument that "Client" is meaningless becomes pretty moot when you >> realise that you can import a *namespace* and use it relatively, if you so >>

Re: [PHP-DEV] PDO subclass names

 Sent from my iPhone > On 23 Apr 2024, at 22:35, Bilge wrote: > On 23/04/2024 10:25, Stephen Reay wrote: >> The argument that "Client" is meaningless becomes pretty moot when you >> realise that you can import a *namespace* and use it relatively, if you so >

Re: [PHP-DEV] [RFC] [Discussion] #[\Deprecated] attribute again v1.3

Sent from my iPhone > On 25 Apr 2024, at 16:26, Rowan Tommins [IMSoP] wrote: > > On 24 April 2024 18:18:28 BST, Jorg Sowa wrote: >> What about setting this parameter vaguely as the boolean we can pass? >> ... >> #[Deprecated(since: $packageVersion > 5.5)] >> #[Deprecated(since: PHP_VERSION_ID

Re: [PHP-DEV] [RFC] [Discussion] #[\Deprecated] attribute again v1.3

Sent from my iPhone > On 26 Apr 2024, at 22:06, Rowan Tommins [IMSoP] wrote: > >  > >> On 26 April 2024 09:40:57 BST, Mike Schinkel wrote: >> >> Given a lack of agreed definition for 'since' it appears you are using >> narrow assumptions about the meaning of 'since' that led you to view '

Re: [PHP-DEV] [Discussion] Implicitly backed enums

> On 22 May 2024, at 07:58, Larry Garfield wrote: > > given that the casing for an enum should be CamelCase (per PER-CS) Hi Larry; I find myself yet again having to ask that php policies/discussions not revolve around the idea that PHP-FIG is a required/expected part of PHP usage. Until a

Re: [PHP-DEV] [Discussion] Implicitly backed enums

Sent from my iPhone > On 23 May 2024, at 03:58, Larry Garfield wrote: > > On Wed, May 22, 2024, at 2:29 AM, Stephen Reay wrote: >>>> On 22 May 2024, at 07:58, Larry Garfield wrote: >>> >>> given that the casing for an enum should be CamelCase (per

Re: [PHP-DEV] Re: [RFC] [Vote] #[\Deprecated] attribute

Sent from my iPhoneOn 24 Jun 2024, at 23:43, Matthew Weier O'Phinney wrote:On Mon, Jun 24, 2024 at 10:08 AM Nicolas Grekas wrote:Le mer. 5 juin 2024 à 10:18, Benjamin Außenhofer a écrit :On Wed, May 22, 2024 at 9:22 AM Benjamin Außenhofer

Re: [PHP-DEV] [RFC] Static class

> On 25 Jun 2024, at 09:22, Mike Schinkel wrote: > >> On Jun 24, 2024, at 3:53 AM, Ayesh Karunaratne > > wrote: >> - Why is it a class-level flag and not an attribute (similar to the >> `#[Override]` attribute in PHP 8.3) ? > > From my perspective that would create much

Re: [PHP-DEV] [RFC] Static class

Hi, > On 25 Jun 2024, at 15:03, Bilge wrote: > > Hi guys, > > On 25/06/2024 04:17, Stephen Reay wrote: >>> Given a primary purpose for being able to declare a class `static` is to >>> signal intent, disallowing `abstract static` classes seems at odds with &g

Re: [PHP-DEV] [RFC] Static class

> On 26 Jun 2024, at 12:51, Mike Schinkel wrote: > >> On Jun 24, 2024, at 11:17 PM, Stephen Reay > <mailto:php-li...@koalephant.com>> wrote: >> >> >> >>> On 25 Jun 2024, at 09:22, Mike Schinkel >> <mailto:m...@newclarity.net>&g

Re: [PHP-DEV] [RFC] Static class

> On 27 Jun 2024, at 10:11, Mike Schinkel wrote: > > Hi Stephen, > >> On Jun 26, 2024, at 4:26 AM, Stephen Reay > <mailto:php-li...@koalephant.com>> wrote: >> >> This is an example of code that works today (and all the way back to 5.0): >> h

Re: [PHP-DEV] [RFC] Static class

> On 27 Jun 2024, at 13:11, Mike Schinkel wrote: > > >> On Jun 27, 2024, at 12:09 AM, Stephen Reay > <mailto:php-li...@koalephant.com>> wrote: >> >> Hi Mike, >> >> To answer your question: I believe `abstract static` should be allow

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

> On 27 Jun 2024, at 12:31, Mike Schinkel wrote: > >> On Jun 26, 2024, at 8:14 AM, Gina P. Banyard > > wrote: >> >> >> On Wednesday, 26 June 2024 at 06:18, Mike Schinkel > > wrote: >>> https://3v4l.org/RDYFs#v8.3.8 >>> >>> Note those seve

Re: [PHP-DEV] [RFC] Static class

> On 28 Jun 2024, at 14:05, Lynn wrote: > > > > On Fri, Jun 28, 2024 at 2:48 AM Mike Schinkel > wrote: >> >> and inheritance is not meant for code reuse. >> >> Just because code reuse in inheritance can be problematic it does not have >> to be in all-cases. Mode

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

> On 29 Jun 2024, at 06:03, Bilge wrote: > > On 28/06/2024 22:35, Niels Dossche wrote: >> - Why did you choose UrlParser to be a "static" class? > > Because "static class" is the hip new cool ;) > > Bilge I would argue that for 90%+ of cases, static *userland* classes are used because of (

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

> On 29 Jun 2024, at 04:48, Niels Dossche wrote: > > - It's a bit of a shame that the PSR interface treats queries as strings. > In Javascript we have the URLSearchParams class that we can use as a > key-value storage for query parameters. > This Javascript class also handles escaping them ni

Re: [PHP-DEV] [Initial Feedback] Typed Arrays

Sent from my iPhoneOn 1 Jul 2024, at 09:03, Richard Miles wrote:There even was an RFC in voting which Joe implemented and it addresses nearly what is discussed it this thread https://wiki.php.net/rfc/arrayof The link above has broken page links to the mailing list. I’ve found the externals.io hi

Re: [PHP-DEV] [Initial Feedback] Typed Arrays

> On 1 Jul 2024, at 10:05, Richard Miles wrote: > > Howdy Stephen, > >>> It seems like everyone always gets really hung up on generics! That or how >>> to syntactically implement this. >> >> Hi >> >> Given other improvements in the language, I don't really see much need for >> the ability

Re: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript)

Sent from my iPhone > On 1 Jul 2024, at 23:33, Mike Schinkel wrote: > Autoloading runs userland code. This means it has the potential conflict > between different packages with different autoloaders *Can* run userland code. It doesn't *have to*; FYI spl_autoload (https://www.php.net/manual/e

Re: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript)

> On 3 Jul 2024, at 21:07, Vincent de Lau wrote: > > From: Stephen Reay > Sent: Wednesday, July 3, 2024 1:17 PM > >> On 1 Jul 2024, at 23:33, Mike Schinkel <mailto:m...@newclarity.net> wrote: >>> Autoloading runs userland code. This means it has the poten

Re: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript)

> On 3 Jul 2024, at 23:51, Matthew Weier O'Phinney > wrote: > > > > On Wed, Jul 3, 2024 at 9:50 AM Stephen Reay <mailto:php-li...@koalephant.com>> wrote: >> >> >>> On 3 Jul 2024, at 21:07, Vincent de Lau >> <mailto:vinc...@d

Re: [PHP-DEV] [RFC] Static class

> On 8 Jul 2024, at 14:42, Bilge wrote: > > On 08/07/2024 01:16, Mike Schinkel wrote: >> Congrats on getting it to this point. > Thanks. It's been an adventure :^) > >> I support this in all but the RFC's restriction on `abstract`, as I have >> previously mentioned on the list. > I must have

Re: [PHP-DEV] Require C11 in PHP 8.4

> On 2 Aug 2024, at 05:26, Derick Rethans wrote: > > On 1 August 2024 22:57:36 BST, Ilija Tovilo > wrote: >> Hi everyone >> >> We've gotten a bug report about compile errors in the PHP 8.4 alpha on >> old C99 compilers (and on some modern compilers when passing

Re: [PHP-DEV] Require C11 in PHP 8.4

> On 6 Aug 2024, at 18:26, Derick Rethans wrote: > > Normal clang supports the same flag. Apple clang potentially too, but > not currently: > https://opensource.apple.com/source/clang/clang-23/clang/tools/clang/docs/UsersManual.html > — it could be outdated information though. I don't have a

Re: [PHP-DEV] Question about adding !function_identifier

> On 4 Apr 2019, at 03:29, M. W. Moe wrote: > > Thanks! > >> On Wed, Apr 3, 2019 at 1:24 PM G. P. B. wrote: >> >> Hello, >> >> I don't really see the point of it as you self said this wouldn't add a >> runtime check, so in what is it different to a comment? >> More so reusing ! for this wi

Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

> On 4 Apr 2019, at 21:14, CHU Zhaowei wrote: > > Hi internals, > > Thanks for the people who joined the discussion of my [RFC: Spread Operator > in Array Expression](https://wiki.php.net/rfc/spread_operator_for_array). The > biggest change is I have dropped the support for string keys in v

Re: [PHP-DEV] RFC Draft: Comprehensions

> On 5 Apr 2019, at 08:54, Larry Garfield wrote: > > On Wed, Mar 13, 2019, at 10:22 PM, Larry Garfield wrote: >> On Wed, Mar 13, 2019, at 6:30 PM, Rowan Collins wrote: >>> On 13/03/2019 21:10, Dik Takken wrote: > >> If I can summarize the responses so far, they seem to fall into one of >> two

Re: [PHP-DEV] [RFC] Nullable Casting

> On 8 Apr 2019, at 16:35, Benjamin Morel wrote: > >> register_cast_function('?int', 'castToIntOrNull'); > > I would quite oppose such a generic implementation, as it might have > unexpected consequences in other parts of the codebase : it's a global > configuration set at runtime. > > I quit

Re: [PHP-DEV] RFC Draft: Comprehensions

> On 5 Apr 2019, at 21:29, Larry Garfield wrote: > > On Thu, Apr 4, 2019, at 10:46 PM, Stephen Reay wrote: > >>> Discussion: >>> >>> For me, the inability to work with arrays is the big problem with the >>> second approach. I

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

> On 10 Apr 2019, at 15:59, Robert Hickman wrote: > >> I'd just like to amplify this mention of 3rd party tooling: if we go with >> something which requires complex lexer/parser rules, then every editor, >> IDE, and static analysis tool will need to also work with that syntax. >> > > Is this

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

> On 11 Apr 2019, at 00:32, M. W. Moe wrote: > > I have never seen ML programmers being improductive; Great. I’ve never seen a pig crash a plane, therefore all pilots should be pigs? Given your previous comments regarding removing “java impurities” it’s hard to take anything you suggest seri

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

> On 11 Apr 2019, at 04:49, Wes wrote: > > The > whole community (not just you) considers short open tags poison because not > XML-compatible... while they use stuff like twig, which is also not > XML-compatible. I can’t say I’ve run into the XML issue in a real environment, but IMO the big ‘

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

> On 14 Apr 2019, at 23:52, Nikita Popov wrote: > > On Mon, Apr 8, 2019 at 4:06 PM Nikita Popov wrote: > >> On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote: >> >>> Hi internals, >>> >>> Motivated by the recent list comprehensions RFC, I think it's time we >>> took another look at short

Re: [PHP-DEV] Object Type Casting Reloaded

> On 23 Apr 2019, at 06:30, azjezz wrote: > > Hello Ben. > > yes, i have made a gist with a simple example to show the `as` operator usage > in hack + HHVM ( 4.1.0 ) output. > > see : https://gist.github.com/azjezz/03955ff2b009f1ced22ce68c9a862847 > > Sent with [ProtonMail](https://protonm

Re: [PHP-DEV] Object Type Casting Reloaded

be an issue > to use it for something else, but i think i will leave that to someone who's > more familiar with the PHP parser than me. > > > Cheers. > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Tuesday, April 23, 2019 1:43 AM,

Re: [PHP-DEV] Object Type Casting Reloaded

> On 23 Apr 2019, at 16:03, Benjamin Morel wrote: > > > I like the idea but I find the syntax (both suggestions) less than great, > > given that there’s already “ensure a type” syntax, and both suggestions are > > already used for other things (casting and foreach) > > Note that we already us

Re: [PHP-DEV] Object Type Casting Reloaded

> On 23 Apr 2019, at 19:32, Benjamin Morel wrote: > > I'm sorry, I still don't understand what the issue with foreach is? As I said > before, the proposed syntax does not aim to be used inside the foreach () > parentheses, but rather as an explicit declaration inside the foreach {} > block.

Re: [PHP-DEV] Object Type Casting Reloaded

> On 23 Apr 2019, at 21:02, Benjamin Morel wrote: > > It's exactly the purpose of the proposal: avoid this boilerplate. For the > same reason you probably write: > Replacing 1 line of “boiler plate” with a *different* line of less-obvious “boiler plate” is not an improvement IMO. > The cur

Re: [PHP-DEV] Object Type Casting Reloaded

> On 23 Apr 2019, at 21:54, Benjamin Morel wrote: > > @Stephen Reay > >> In languages without type hinting (e.g. JavaScript) - the “boiler plate” > you’re trying to remove is also common, e.g. using `typeof` in JavaScript. > > It's also very common to *not

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

> On 24 Apr 2019, at 21:00, Lester Caine wrote: > > On 24/04/2019 14:41, vsura...@gmail.com wrote: >> A 68% majority which barely clears the 2/3 requirements for something as >> fundamental as that - with so many core devs against it - we'll deserve all >> the criticism that will be coming ou

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

> On 24 Apr 2019, at 21:35, Chase Peeler wrote: > > If I get started now, maybe I can have everything fixed by the time 8.1 is > released. Two characters less than this sentence of yours is a 1-liner find/sed script to replace all `

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

> On 24 Apr 2019, at 21:56, Lester Caine wrote: > > I've looked at these 'automatic tools' and until there is one that does not > enforce their own views of code style they are just another nail While the pre-build rules may not be what you want - something like PHP_CodeSniffer will let you

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

> On 24 Apr 2019, at 22:16, Chase Peeler wrote: > > > > On Wed, Apr 24, 2019 at 11:02 AM Stephen Reay <mailto:php-li...@koalephant.com>> wrote: > > > On 24 Apr 2019, at 21:35, Chase Peeler > <mailto:chasepee...@gmail.com>> wrote: > > &g

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

> On 25 Apr 2019, at 14:11, Thomas Hruska wrote: > sed-based solutions do NOT work. > Neither of the two recommended options to date on this list are valid > recommendations for serious software deployment managers. I have no issue with suggesting tools to fix short opening tags, but lay of

Re: [PHP-DEV] Proposal for a RFC

> On 7 May 2019, at 19:22, Nikita Popov wrote: > > On Tue, May 7, 2019 at 2:20 PM Steven Wade wrote: > >>> I want to weight in with what Marco expressed. I have the very same >> concerns and they are major ones for many use cases. Mine is VarDumper. >>> >>> Please don't do this the way it is

Re: [PHP-DEV] Proposal for a RFC

> On 7 May 2019, at 19:47, Steven Wade wrote: > >> Maybe I’m missing the point (I’ve never used it) of VarDumper, but isn’t >> this type of thing exactly why the `__debugInfo` magic method exists? > > > I can't speak for the exact reason a library like VarDumper is using casting > versus __

Re: [PHP-DEV] Error instead of returning false

> On 7 May 2019, at 22:15, Claude Pache wrote: > > If you do think that ideally an exception should be thrown here, it is better > to devise a new function—and, while you’re at it, a function that returns an > object of some definite class instead of a resource. Isn’t this exactly what SplFi

Re: [PHP-DEV] [VOTE] Strict operators directive

> On 9 Jul 2019, at 17:06, Christian Schneider wrote: > > When you drop the declaration on top of the file the semantics of your > operators suddenly change, e.g. > "42" < "7" > changes from true to false and you get subtle bugs. If you OPT IN to strict operators, the onus is on you to

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

> On 29 Jul 2019, at 22:34, Rowan Collins wrote: > > I guess what I had in mind was that *in the long-term*, > out/inout parameters would replace & parameters, Excuse my ignorance (presumably about the complexity involved) if this is obvious, but if out/inout parameters are considered to be

Re: [PHP-DEV] Bringing Peace to the Galaxy

> On 9 Aug 2019, at 12:11, Brent wrote: > > Hi Zeev > > Happy to see this proposal pop up, it's good to know that the "other side" is > also open for long-term solutions. I think there needs to be a thorough > analysis about the pros and cons of the two paths to take: a sister language > vs

Re: [PHP-DEV] Call for participation: Annotating internal function argument and return types

> On 10 Aug 2019, at 17:56, Nikita Popov wrote: > > Hi, > > Lack of type information for internal functions in Reflection is a > long-standing issue. In PHP 8 we finally have all the necessary technical > groundwork done to support argument and return type annotations on internal > functions a

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

> On 12 Aug 2019, at 15:26, Nikita Popov wrote: > > On Mon, Aug 12, 2019 at 10:17 AM Nicolas Grekas < > nicolas.grekas+...@gmail.com> wrote: > >> Le lun. 11 déc. 2017 à 14:44, Nikita Popov a >> écrit : >> >>> Some time ago I introduced the following proposal for namespace-scoped >>> declares

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

> On 14 Aug 2019, at 00:05, Rowan Collins wrote: > >> On 13/08/2019 12:01, Mark Randall wrote: >>> On 13/08/2019 10:02, Rowan Collins wrote: >>> I really like this approach. It allows a package definition file to exist, >>> without either the language or the header of each file having to defi

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

> On 28 Aug 2019, at 23:04, Chase Peeler wrote: > > On Wed, Aug 28, 2019 at 11:37 AM Kalle Sommer Nielsen wrote: > >> Hi >> >> Den ons. 28. aug. 2019 kl. 17.54 skrev Chase Peeler >> : >>> You going to come and fix the issues? It's an internal application and >>> most of those messages are c

Re: [PHP-DEV] Union Class Types (was Union Type (singular) straw man proposal)

> On 6 Sep 2019, at 11:22, Mike Schinkel wrote: > > Hi Côme, > >> This example is really confusing me more than anything else. > > > Thank you very much for your feedback. You illustrated perfectly why I > should not have produced that proposal in haste. > > Your confusion was due to my f

Re: [PHP-DEV] Union Class Types (was Union Type (singular) straw man proposal)

ossible to get type safety from using __toString() in a manner as I am > struggling to envision one? > >> tthat a class can be safely cast to another type when used with typed >> properties/arguments/returns. > > What about for types where there is no syntax for ca

Re: [PHP-DEV] Union Class Types (was Union Type (singular) straw man proposal)

> On 6 Sep 2019, at 17:21, Mike Schinkel wrote: > > Hi Stephen, > > Thank you again for the reply. > >> and wasn’t really built for that purpose AFAIK, but in ‘weak’ mode (i.e. no >> strict_types=1) it would be invoked if the destination type specified a >> string. I was implying that this

  1   2   3   >