Re: [PHP-DEV] [RFC] Policy on 3rd party code

Sent from my iPhone > On 6 Oct 2024, at 09:38, Larry Garfield wrote: > > On Sat, Oct 5, 2024, at 12:30 PM, Stephen Reay wrote: >>>> On 3 Oct 2024, at 01:48, Larry Garfield wrote: >>> >>> Since Jim's RFC proposal was criticized for being to

Re: [PHP-DEV] [RFC] Policy on 3rd party code

> On 3 Oct 2024, at 01:48, Larry Garfield wrote: > > Since Jim's RFC proposal was criticized for being too vague, I hereby offer > a somewhat more prescriptive policy proposal on using 3rd party code. (With > JIm's blessing.) It's still more heuristics than rules, but I think that's > the

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] [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] [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 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 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 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 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 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 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 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 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 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 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 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: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] 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] 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

> 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] 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] 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] [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] 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] 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)

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] [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] [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] [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] [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] 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] 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 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] 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 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

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 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] 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] [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] [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] [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] [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] 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] 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 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] [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] 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 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] [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 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 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] 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] 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] 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] 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 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 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] [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] [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 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 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] 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] 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] 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 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] 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] 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] 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] First-class callable partial application

> On 17 Mar 2023, at 05:33, Larry Garfield wrote: > > On Thu, Mar 16, 2023, at 4:14 AM, Rowan Tommins wrote: >>> On 15/03/2023 21:12, Dan Ackroyd wrote: >>> Would it be desirable to split those two things into two separate >>> RFCs, by having the first RFC not have native syntax support, but >

Re: [PHP-DEV] Class Re-implementation Mechanism

> On 21 Feb 2023, at 18:52, someniatko wrote: > > Hi again, internals > > My marathon of some crazy ideas continues :D, with less crazy one this time. > > > ## Idea > > Allow "reimplementing" the non-static public API (that is public > properties and methods, excluding constructor) of a cl

Re: [PHP-DEV] Methods which auto-return the class instance

> On 25 Dec 2022, at 12:59, Ilija Tovilo wrote: > > Hi Daniele > >> On Fri, Dec 23, 2022 at 1:09 AM joke2k wrote: >> >> Hi folks, >> >> What do you think about having a method which returns the class instance >> `$this` by default only IF its return type is set as `self`? >> >> It is very

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> On 12 Dec 2022, at 02:18, Larry Garfield wrote: > > On Thu, Dec 1, 2022, at 12:31 PM, Tim Düsterhus wrote: >> Hi >> >> On 11/29/22 21:29, Larry Garfield wrote: >>> Thank you everyone for the feedback. Based on this thread, we've made two >>> changes to the RFC: >>> >>> 1. We've moved rea

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> On 2 Dec 2022, at 18:31, Ilija Tovilo wrote: > > Hi Stephen > >> So here’s my last attempt: >> >> Please change this behaviour in your rfc. >> >> You are explicitly making it mutually exclusive with readonly now, so that’s >> not a bc break - if/when it becomes compatible with readonly th

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> On 2 Dec 2022, at 01:21, Larry Garfield wrote: > > On Wed, Nov 30, 2022, at 7:38 PM, Stephen Reay wrote: > >>>> So please, can you explain to me why consistency with an implementation >>>> detail of readonly properties is more important than cons

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> On 1 Dec 2022, at 08:38, Stephen Reay wrote: > > > >> On 30 Nov 2022, at 22:09, Larry Garfield wrote: >> >> On Tue, Nov 29, 2022, at 11:25 PM, Stephen Reay wrote: >> >>> Hi Larry, >>> >>> Thank you for clarifying the sett

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> On 30 Nov 2022, at 22:09, Larry Garfield wrote: > > On Tue, Nov 29, 2022, at 11:25 PM, Stephen Reay wrote: > >> Hi Larry, >> >> Thank you for clarifying the setter behaviour in more explicit terms, >> but I have to say I’m quite disappointed in

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> On 30 Nov 2022, at 15:41, Alexandru Pătrănescu wrote: > > > On Wed, Nov 30, 2022, 05:25 Stephen Reay <mailto:php-li...@koalephant.com>> wrote: > > > > On 30 Nov 2022, at 08:27, Larry Garfield > <mailto:la...@garfieldtech.com>> wrote: >

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> On 30 Nov 2022, at 08:27, Larry Garfield wrote: > > On Tue, Nov 29, 2022, at 5:46 PM, Claude Pache wrote: > >> In the RFC, section Permitted visibility >> (https://wiki.php.net/rfc/asymmetric-visibility#permitted_visibility >>

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> On 14 Nov 2022, at 03:08, Larry Garfield wrote: > > Hi folks. Ilija is nearly done with the implementation for asymmetric > visibility and flushing out edge cases, but we've run into one design > question we'd like feedback on. > > There's two design decisions we've made at this point, bot

Re: [PHP-DEV] Newcomer, PHP pre-processing, Magic Constants __FILE__ and __LINE__ override with #line like in C

> On 23 Oct 2022, at 20:43, Ludovic Pouzenc wrote: > > Hi, > > I'm a newcomer here. I came from https://wiki.php.net/rfc/howto. > > *TL;DR:* I want to know if a proposal of a #line parsing to alter __FILE__ > and __LINE__ in PHP like it exists in C could be a good idea. > > I've searched ab

Re: [PHP-DEV] Union type casts

> On 5 Oct 2022, at 12:41, Dusk wrote: > > On Oct 4, 2022, at 21:46, Eugene Sidelnyk wrote: >> $foo = (int|float)$bar; > > As written, I wouldn't know what to expect this to do with a string value -- > would it cast it to int or float? > > Based on the behavior of your second example, th

Re: [PHP-DEV] [RFC] Asymmetric visibility

> On 8 Aug 2022, at 20:21, Rowan Tommins wrote: > > On 08/08/2022 10:09, Stephen Reay wrote: >> The RFC states that it’s to keep consistency with `readonly`, because __set >> on a readonly property that’s initialised throws an error - but isn’t that >> becaus

Re: [PHP-DEV] [RFC] Asymmetric visibility

> On 6 Aug 2022, at 00:08, Larry Garfield wrote: > > Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3: > Asymmetric Visibility. > > https://wiki.php.net/rfc/asymmetric-visibility > > Details are in the RFC, but it's largely a copy of Swift's support for the > same. > >

Re: [PHP-DEV] [RFC] [VOTE] Constants in traits

> On 11 Jul 2022, at 09:10, Mike Schinkel wrote: > >> On Jul 5, 2022, at 5:38 PM, shinji igarashi wrote: >> >> Hello internals, >> >> I've started the vote for the Constants in Traits RFC: >> https://wiki.php.net/rfc/constants_in_traits >> >> The vote will end on 19. July 2022. >> >> Thank

Re: [PHP-DEV] Re: [RFC] [Under Discussion] PDO driver specific sub-classes

> On 24 Jun 2022, at 22:45, Dan Ackroyd wrote: > > Larry Garfield wrote: > >> "Create all DB sub-classes?" - I'd say they all should have subclasses, even >> if empty. It's more consistent* that way, and you can then also rely on >> instanceof giving you useful information rather than "well,

Re: [PHP-DEV] [RFC] [Under Discussion] PDO driver specific sub-classes

Sent from my iPhone > On 21 Jun 2022, at 06:08, Dan Ackroyd wrote: > > Hi, > > Following previous discussions, here is an RFC to have DB specific > classes for PDO. > > https://wiki.php.net/rfc/pdo_driver_specific_subclasses > > cheers > Dan > Ack > > -- > PHP Internals - PHP Runtime D

Re: [PHP-DEV] Adding `final class Deque` to PHP

> On 1 Feb 2022, at 21:46, tyson andre wrote: > > Hi internals, > >> I've created a new RFC https://wiki.php.net/rfc/deque to add a `final class >> Deque` >> >> This is based on the `Teds\Deque` implementation I've worked on >> for the https://github.com/TysonAndre/pecl-teds PECL. >> >> Whi

Re: [PHP-DEV] Is there an RFC/discussion for ::class being a specific type?

> On 17 Nov 2021, at 00:22, André Hänsel wrote: > > It is common (with DI systems for example) and to my knowledge not > particularly discouraged to have function parameters that are supposed to > accept something like Foo::class, which currently is a string. > > It seems logical to ask for a

Re: [PHP-DEV] [RFC] [VOTE] is_literal

> On 8 Sep 2021, at 13:33, Claude Pache wrote: > > > >> Le 7 sept. 2021 à 11:49, Craig Francis a écrit : >> >> >> Obviously I'd still like libraries to be able to protect everyone from >> introducing Injection Vulnerabilities (as the majority of programmers don't >> use static analysis),

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

> On 29 Jun 2021, at 02:28, Jan Ehrhardt wrote: > > Nikita Popov in php.internals (Mon, 22 Mar 2021 10:24:51 +0100): >> Hi internals, >> >> It's time for another deprecation RFC: >> https://wiki.php.net/rfc/deprecations_php_8_1 > > FWIW, a quick search returned these results. > > ADOdb stil

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

> On 24 Jun 2021, at 17:16, Craig Francis wrote: > > On Thu, 24 Jun 2021 at 10:55, Stephen Reay wrote: > >> but still I have to keep asking: Why integers at all? >> > > > While I'm not a fan of this approach, there is a lot of existing code and >

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

> On 24 Jun 2021, at 17:07, Kamil Tekiela wrote: > > Hi Stephen, > > I believe the idea was for dynamically generate table names, or numbered > tables/columns. E.g. > > function getTable(string $table){ > // is_literal check here > } > > $number = (int) $_GET['tableno']; > if($number

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

> On 24 Jun 2021, at 14:29, Scott Arciszewski wrote: > > On Thu, Jun 24, 2021 at 2:10 AM Stephen Reay wrote: >> >> >> >> On 24 Jun 2021, at 08:30, Scott Arciszewski wrote: >> >> On Wed, Jun 23, 2021, 9:23 PM Bruce Weirdan wrote: >> &

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

> On 24 Jun 2021, at 14:14, Scott Arciszewski wrote: > > On Thu, Jun 24, 2021 at 2:10 AM Stephen Reay wrote: >> Hi Scott, >> >> I wrote that example where an integer could be dangerous. > > I don't disagree that it's an example where an integer c

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

> On 24 Jun 2021, at 08:30, Scott Arciszewski wrote: > > On Wed, Jun 23, 2021, 9:23 PM Bruce Weirdan > wrote: > >> On Thu, Jun 24, 2021 at 3:41 AM Scott Arciszewski >> wrote: >>> The failure condition of this query is >>> "return all rows from the table already bein

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

Sent from my iPhone > On 23 Jun 2021, at 03:08, Lauri Kenttä wrote: > > On 2021-06-22 21:38, Stephen Reay wrote: >>>> On 22 Jun 2021, at 21:38, Craig Francis wrote: >>> If you can point me to an example where including integers in this has >>> introduc

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

> On 22 Jun 2021, at 21:38, Craig Francis wrote: > > If you can point me to an example where including integers in this has > introduced a security vulnerability then please do, and I mean it, that’s > what this process is for, I genuinely want people to come forward with them > so we can refin

Re: [PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC] is_literal)

> On 22 Jun 2021, at 20:39, Mike Schinkel wrote: > >> On Jun 22, 2021, at 9:00 AM, Kamil Tekiela wrote: >> >> Hi Mike, >> >> Please don't do this. We already have PDO with prepared statements. The data >> must be bound. This is the secure way of writing SQL queries. > > The problem is th

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

> On 22 Jun 2021, at 20:13, Craig Francis wrote: > > On Tue, 22 Jun 2021 at 09:59, Stephen Reay <mailto:php-li...@koalephant.com>> wrote: > So I just want to make sure I understand the progression on this so far. It > started out with people wanting a way to check tha

  1   2   3   >