<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Len Woodward</title>
    <description>The latest articles on DEV Community by Len Woodward (@projektgopher).</description>
    <link>https://dev.to/projektgopher</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F1383734%2Ff5ede504-5ae0-422b-8d13-69b3bfd2a1a1.jpeg</url>
      <title>DEV Community: Len Woodward</title>
      <link>https://dev.to/projektgopher</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/projektgopher"/>
    <language>en</language>
    <item>
      <title>This Week In PHP Internals | July 29, 2026</title>
      <dc:creator>Len Woodward</dc:creator>
      <pubDate>Sun, 02 Aug 2026 08:07:27 +0000</pubDate>
      <link>https://dev.to/projektgopher/this-week-in-php-internals-july-29-2026-45ge</link>
      <guid>https://dev.to/projektgopher/this-week-in-php-internals-july-29-2026-45ge</guid>
      <description>&lt;p&gt;Hello world, from &lt;strong&gt;Laracon US 2026&lt;/strong&gt; in Boston — it's Wednesday, July 29, 2026, and here's what happened This Week in PHP Internals.&lt;/p&gt;

&lt;p&gt;15 stories this week, so let's get into it. &lt;em&gt;But first,&lt;/em&gt; This week's episode is brought to you by &lt;strong&gt;Tideways&lt;/strong&gt;. When a request is slow and your logs won't say why, Tideways shows you where the time went — profiling, tracing, and monitoring built &lt;strong&gt;specifically&lt;/strong&gt; for PHP. Slow request to root cause, in minutes. Setup takes 5 minutes, no credit card required. Start your free trial at &lt;code&gt;tideways.com&lt;/code&gt;. And we have a &lt;strong&gt;second&lt;/strong&gt; sponsor this week — &lt;strong&gt;Geocodio&lt;/strong&gt;: address correction, geocoding, data enrichment, and distance calculations for North America and the UK. Built on Laravel since 2014. Try it free at &lt;code&gt;geocod.io&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;This week's top story: the mass deprecation vote for PHP &lt;code&gt;8.6&lt;/code&gt; is open. Gina P. Banyard opened it Monday, and it's &lt;strong&gt;35&lt;/strong&gt; separate ballots, each needing its own 2/3 majority — and each submitted individually, because as Gina reminded everyone, the wiki can only handle one vote at a time. Voting runs through August 10, and most of the 35 are passing easily — &lt;code&gt;mysqli_get_charset()&lt;/code&gt; stands at 34 to &lt;strong&gt;nothing&lt;/strong&gt;, and &lt;code&gt;spl_classes()&lt;/code&gt; at 33 to nothing. But the headliners are moving the other way. &lt;code&gt;list()&lt;/code&gt; — the construct Juliette Reinders Folmer's Packagist scan found over twelve thousand times — stands at 17 yes to 19 &lt;strong&gt;no&lt;/strong&gt;, falling well below the required two-thirds threshold. The gettext &lt;code&gt;_()&lt;/code&gt; alias is failing at 6 to 18. Reserving &lt;code&gt;in&lt;/code&gt;, &lt;code&gt;out&lt;/code&gt;, and &lt;code&gt;inout&lt;/code&gt; is failing at 5 to 16, with 13 abstentions. And &lt;code&gt;let&lt;/code&gt; sits at 17 to 10 — a majority, but still shy of 2/3.&lt;/p&gt;

&lt;p&gt;The loudest argument is about one of the smallest items: the &lt;code&gt;dechunk&lt;/code&gt; stream filter, which as of recording sits at 15 yes to 13 &lt;strong&gt;no&lt;/strong&gt; — a coin-flip vote on a 2/3 question. On Monday, Matteo Beccati was the &lt;em&gt;only&lt;/em&gt; no vote, and he explained why, warning: "I believe we should provide such an alternative together with the deprecation," rather than expecting projects with 200-million-plus installations — he names &lt;code&gt;symfony/http-client&lt;/code&gt; — to write their own decoder in PHP. Jakub Zelenka agreed the item wasn't ready, saying it "should wait till it's properly investigated." Pierre Joye ran his own usage research and pushed back, noting: "Being present in a code base does not automatically mean it is used" — Symfony's native client disables the filter by default, and most stacks sit on curl anyway. Matteo then corrected the research: Symfony has shipped a pure-PHP alternative since release &lt;code&gt;8.2&lt;/code&gt;, which is exactly why Pierre's search pointed the wrong way. Jakub's objection sharpened from there, and he wrote: "This is exactly a half baked deprecation because we need to keep it for internal use anyway ... so this does not give us any code removal and we still need to maintain it. I don't understand why we need to rush it as there is no real reason for that." By Tuesday evening he'd also revealed a twist — he already fixed the select limitation on filtered streams in master, so that improvement lands in &lt;code&gt;8.6&lt;/code&gt; no matter how this ballot goes. Kamil Tekiela, meanwhile, asked a different question — why deprecate &lt;code&gt;define()&lt;/code&gt;'s dead case-insensitive flag at all, when just removing the parameter breaks nobody. So far, nobody has answered him.&lt;/p&gt;

&lt;p&gt;Caleb White's pipe assignment operator, &lt;code&gt;|&amp;gt;=&lt;/code&gt; — the compound form of the pipe, and his first RFC — went to ballot Tuesday morning, walked to the deadline with detailed coaching from Tim Düsterhus, whom Caleb thanked for "going to bat for this RFC". The machinery worked; the voters are split right down the middle — as of recording the count is 8 yes, 8 &lt;strong&gt;no&lt;/strong&gt;, 3 abstaining, and it needs 2/3. Voting runs to August 11.&lt;/p&gt;

&lt;p&gt;The queue from last week showed up on time. Nick Sdot opened voting on &lt;strong&gt;readonly property defaults&lt;/strong&gt; Friday. It stands at 17 to nothing, with 5 abstentions — nobody's against it yet. That one closes August 7. And Khaled Alam opened voting Saturday on &lt;strong&gt;const object property writes&lt;/strong&gt; — allowing writes to properties of objects referenced by constants. After a couple of quickly-fixed procedural stumbles, the count stands at 11 to 2, with 5 abstentions — above the 2/3 line. That one closes August 8.&lt;/p&gt;

&lt;p&gt;Two carryover votes come off the board this week, and neither thread needed a single new email. The minimum-supported-versions vote for &lt;code&gt;8.6&lt;/code&gt; closes &lt;strong&gt;Thursday&lt;/strong&gt;. Requiring &lt;code&gt;autoconf&lt;/code&gt; 2.71 stands at 27 to 2 — and notably, the no column &lt;em&gt;shrank&lt;/em&gt; from 3 to 2 since last week. Requiring &lt;code&gt;COM_RESET_CONNECTION&lt;/code&gt; stands at 26 to nothing. And the &lt;code&gt;Time\Duration&lt;/code&gt; class closes &lt;strong&gt;Friday&lt;/strong&gt;. The primary has stretched to 33 to 1, and full method names — &lt;code&gt;multiplyBy&lt;/code&gt;, &lt;code&gt;divideBy&lt;/code&gt; — lead the naming question 28 to 2. Barring a very strange 48 hours, PHP &lt;code&gt;8.6&lt;/code&gt; gets a &lt;code&gt;Duration&lt;/code&gt; class.&lt;/p&gt;

&lt;p&gt;Seifeddine Gmati's &lt;strong&gt;literal scalar types&lt;/strong&gt; made it to a ballot Thursday morning — for 18 minutes. At 5:26 UTC he opened the vote, 3 questions deep: integer and string literals, float literals, and strict-versus-coercive matching. At 5:44 he pulled it back down, writing: "I am retracting this vote: I opened it prematurely, in violation of the voting prerequisites in the Feature Proposals policy." No intent-to-vote 2 days ahead — and that morning's 1.0 update was a &lt;em&gt;minor change&lt;/em&gt;, which starts a 7-day cooldown. He plans to reopen tomorrow, July 30 — a date that brushes right up against the freeze, so it may yet retarget &lt;code&gt;8.7&lt;/code&gt;. The self-retraction turned into a referendum on the process itself. Juris Evertovskis — a longtime reader and one-time RFC author who says he never felt "internal enough" to comment on the process — decided to comment on the process: "All the mandatory cooldowns, cooldown resets on minor changes, announcements to vote, cooldown resets on inactive discussions appears to me like bureaucratic hoops that people have to jump through. The process was hard and daunting enough before this." Bob Weinand agreed, noting he voted against the process RFC back then, and framed the trade plainly: "You sort of have to decide what you optimize for - easier for authors, or easier for commenters. But I think in this case it went way overboard in terms of strictness."&lt;/p&gt;

&lt;p&gt;The &lt;code&gt;gd&lt;/code&gt; 2.4 timing dispute from last week wound down to closing statements, and they were constructive ones. Pierre Joye's position: the late arrival was unavoidable — the libgd sync had to survive PHP's full CI matrix first — and he argued: "Process has to be humane ... If they are purely for the sake of having a process, we fail as a project and solve users' needs." Rowan Tommins made the case that this isn't red tape but triage: "There are maybe twenty sections describing details of the proposal, and the crude [reading-time] estimate in Firefox is 47-60 minutes. It may be clear in your head that most of this is uncontroversial, but for anyone else to even make that judgement requires investing a reasonable amount of time." Better, he says, to spend that time on &lt;code&gt;8.6&lt;/code&gt; work now and this RFC after — though he left open whether the cut-off itself sits in the right place. One concrete footnote: Pierre added the procedural &lt;code&gt;gd&lt;/code&gt; image functions to the deprecation path — on his telling, a warning from the &lt;code&gt;gd&lt;/code&gt; extension itself in &lt;code&gt;8.7&lt;/code&gt;, and gone in PHP 9.&lt;/p&gt;

&lt;p&gt;Derick Rethans hit a fresh regression on master: his Xdebug test suite started failing, and the trail led to the commit implementing the display-error-function-args RFC. Stream warnings from &lt;code&gt;include&lt;/code&gt;, &lt;code&gt;require&lt;/code&gt;, &lt;code&gt;bzopen()&lt;/code&gt;, &lt;code&gt;finfo_open()&lt;/code&gt; and friends no longer say &lt;strong&gt;which file&lt;/strong&gt; couldn't be opened — the path was an argument, and arguments got scrubbed. Derick's verdict was blunt, arguing this "Doesn't seem to me like an enhanced for users" — either put the filename into the message text itself, or revert the change, RFC or not. Kamil Tekiela defended the new behavior, countering: "The file path could leak sensitive information". His suggestion runs the other direction — fold the path into &lt;strong&gt;all&lt;/strong&gt; stream error messages deliberately, rather than leaking it by accident — and while he's at it, he'd rather streams stopped raising their own duplicate warnings entirely. With &lt;code&gt;open_basedir&lt;/code&gt; in effect, one failed &lt;code&gt;include&lt;/code&gt; currently earns you &lt;strong&gt;3&lt;/strong&gt; warnings.&lt;/p&gt;

&lt;p&gt;Edmond of the TrueAsync project turned last week's zero-reply pre-RFC into a real one: &lt;strong&gt;Concurrency Support in the PHP Engine&lt;/strong&gt;. The pitch is deliberately minimal — give the engine a coroutine representation and make the scheduler &lt;em&gt;pluggable&lt;/em&gt; by extensions. He was explicit about the shape of it, writing: "It adds no classes, no functions, no constants and no syntax: the engine compiles in no PHP symbols at all. With no scheduler registered, PHP behaves exactly as it does today." This is not True Async — it's the seam True Async would plug into, alongside anyone else. A scheduler can adopt fibers started by ReactPHP, Revolt, or AMPHP; there's per-coroutine storage that could someday make &lt;code&gt;ob_start()&lt;/code&gt; coroutine-safe; and there is no parallelism — everything stays on one OS thread. The implementation already exists as a pull request. And this time he got a reply. Seifeddine Gmati expects the real discussion to wait until after &lt;code&gt;8.6&lt;/code&gt; ships, but his early read was warm: "Overall, I really like this idea and approach. I think this is the right path forward." Edmond's answer: no rush.&lt;/p&gt;

&lt;p&gt;Osama Aldemeery — who got his RFC karma in 2 minutes flat last week — shipped the RFC: &lt;code&gt;PREG_THROW_ON_ERROR&lt;/code&gt;. Pass the flag to any &lt;code&gt;preg_*()&lt;/code&gt; call and a PCRE failure throws a catchable &lt;code&gt;PregException&lt;/code&gt;, instead of a warning plus a &lt;code&gt;false&lt;/code&gt; or &lt;code&gt;null&lt;/code&gt; you have to notice and then chase through &lt;code&gt;preg_last_error()&lt;/code&gt;. It's the same pattern &lt;code&gt;JSON_THROW_ON_ERROR&lt;/code&gt; already set, and it's strictly opt-in. He stressed the conservatism, writing: "A call does exactly the same thing with it or without it, byte for byte" — the flag only changes how the error is &lt;em&gt;delivered&lt;/em&gt;. It targets the release &lt;strong&gt;after&lt;/strong&gt; &lt;code&gt;8.6&lt;/code&gt;, and he's aware of Larry Garfield's request to hold non-8.6 business until September — his compromise is to let the thread tick over quietly rather than restart it. So far it has 0 replies.&lt;/p&gt;

&lt;p&gt;Quick hits. The &lt;code&gt;8.6&lt;/code&gt; release managers posted the 2-week warning: beta 1 lands Thursday, August 13, the soft freeze hits when the tag is created August 11, and every RFC vote targeting &lt;code&gt;8.6&lt;/code&gt; must be &lt;strong&gt;closed&lt;/strong&gt; before beta 1 — after that, merges need release-manager approval until the hard freeze at RC 1 on September 22. The &lt;code&gt;CURLOPT_HTTPHEADER&lt;/code&gt; newline thread came back with a verdict from upstream: Sjoerd Langkemper relayed word from curl's own Daniel Stenberg that the docs already say headers "must not be CRLF-terminated" and libcurl may start rejecting the stragglers outright — there's a curl pull request in flight. Matteo Beccati's conclusion was to stand down, saying: "libcurl will eventually take care of it." And Steven Wilton's &lt;code&gt;snmp&lt;/code&gt; extension work is back at the finish line — both reworked PRs updated per Gina P. Banyard's review, awaiting a final squash-and-merge check, with a third PR queued behind them.&lt;/p&gt;

&lt;p&gt;The PEAR decay story found a new symptom: Juliette Reinders Folmer reports that individual bug pages on the PEAR site now error out claiming the original reporter "has not yet confirmed their email address" — which locks away exactly the archaeology she'd argued is worth preserving. And the typed-arrays thread got its epilogue: Larry Garfield explained why PHP probably won't get new base types for collections — the engine makes that "really really hard", which is the same reason enums became objects — shared his and Derick Rethans's old collections research notes, and set the course: wait for reified generics, then convene a working group. Holly Schilling's counter-offer was to skip the wait, pointing everyone at her self-published PHP 9 roadmap — generics, structs, modules, extensions, and surfaces — which she'd like the list to treat "as a rough outline for the future."&lt;/p&gt;

&lt;p&gt;So that's the week: &lt;strong&gt;42&lt;/strong&gt; ballots open at once — the 35 deprecations, with &lt;code&gt;list()&lt;/code&gt; headed for defeat and &lt;code&gt;dechunk&lt;/code&gt; splitting the room; pipe assignment dead even out of the gate; readonly defaults and const writes both comfortably clear; &lt;code&gt;Duration&lt;/code&gt; and minimum versions closing within days, both far ahead; a literal-types vote that lasted 18 minutes and reopens tomorrow; and the soft freeze 2 weeks out. Links to every thread are below. Thanks again to &lt;code&gt;Tideways.com&lt;/code&gt; and &lt;code&gt;Geocod.io&lt;/code&gt; for supporting this week's episode. We're Artisan Build. See you next week.&lt;/p&gt;

</description>
      <category>php</category>
      <category>laravel</category>
      <category>news</category>
      <category>webdev</category>
    </item>
    <item>
      <title>This Week In PHP Internals | July 22, 2026</title>
      <dc:creator>Len Woodward</dc:creator>
      <pubDate>Thu, 23 Jul 2026 05:10:06 +0000</pubDate>
      <link>https://dev.to/projektgopher/this-week-in-php-internals-july-22-2026-4gij</link>
      <guid>https://dev.to/projektgopher/this-week-in-php-internals-july-22-2026-4gij</guid>
      <description>&lt;p&gt;Hello world, it's Wednesday, July 22, 2026, and here's what happened This Week in PHP Internals.&lt;/p&gt;

&lt;p&gt;20 stories this week, so let's get into it. &lt;em&gt;But first,&lt;/em&gt; This week's episode is brought to you by &lt;strong&gt;Tideways&lt;/strong&gt;. Slow requests, and no clear reason why? Tideways helps you understand exactly where your PHP application spends its time — profiling, tracing, and monitoring to find and fix bottlenecks &lt;strong&gt;faster&lt;/strong&gt;. And your profiling data stays hosted in Germany — GDPR-friendly by default. Learn more at &lt;code&gt;tideways.com&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;This week's top story: the season's first ballots are open — 2 sets of them — and the early counts are lopsided. Tim Düsterhus opened voting on the &lt;code&gt;Time\Duration&lt;/code&gt; class on Friday with 2 ballots: a primary, needing a 2/3 majority, and a secondary choosing between full and abbreviated method names. As of recording, the primary stands at &lt;strong&gt;23 to 1&lt;/strong&gt;, and full names lead 18 to 1 — so &lt;code&gt;multiplyBy&lt;/code&gt; and &lt;code&gt;divideBy&lt;/code&gt;, not &lt;code&gt;mul&lt;/code&gt; and &lt;code&gt;divBy&lt;/code&gt;. Voting closes July 31. And remember Pierre Joye, who last week was leaning no over &lt;code&gt;fromSeconds()&lt;/code&gt; and its capped nanoseconds argument? This week he closed the loop and voted &lt;strong&gt;yes&lt;/strong&gt;, writing: "We were like ships passing in the night for some of my disagreements. The RFC wiki page did not show the additional constructor for other units, which hence the inconsistency I pointed out for the extra [nanoseconds] argument in fromSecond. They are here, and reduce this down to a lower level of bad APIs, more a pragmatic compromise conciliating different (if not numerous) use cases. Anything can be perfect, or shipped. Choose one." It turns out the per-unit constructors that resolved his objection had been in the RFC all along. His ballot almost didn't register, though — each vote on the wiki is a separate form, and Tim had to point out that you submit each one individually. The count now includes him.&lt;/p&gt;

&lt;p&gt;Before the ballots opened, the &lt;code&gt;Duration&lt;/code&gt; thread picked up a subplot about PHP 9. Holly Schilling — who wrote the class-extensions RFCs we covered last week — announced she's drafting a &lt;strong&gt;Value Structs&lt;/strong&gt; proposal for after the &lt;code&gt;8.6&lt;/code&gt; window, and argued that &lt;code&gt;Duration&lt;/code&gt; would make a better struct than a class, with both ideally landing together in PHP 9. Ilija Tovilo replied by linking his own existing &lt;code&gt;structs-v2&lt;/code&gt; draft and asking whether she was aware of it. She was — she'd read it before drafting her own, and diverged from it on purpose, keeping mutating and non-mutating functionality separate. Tim saw no reason to wait on any of this, saying a draft-stage idea "will take an unknown duration to land - if it ever happens" — &lt;em&gt;his pun, not mine&lt;/em&gt; — and that improvements to the standard library shouldn't queue behind it.&lt;/p&gt;

&lt;p&gt;The week's other live vote came from Eric Norris, who opened balloting Thursday on &lt;strong&gt;minimum supported versions&lt;/strong&gt; for PHP &lt;code&gt;8.6&lt;/code&gt; — also with 2 questions, each needing a 2/3 vote. Requiring autoconf &lt;code&gt;2.71&lt;/code&gt; for builds from git stands at 20 to 3 with 4 abstentions. Requiring &lt;code&gt;COM_RESET_CONNECTION&lt;/code&gt; — which sets a floor of MySQL &lt;code&gt;5.7.3&lt;/code&gt; or MariaDB &lt;code&gt;10.2.4&lt;/code&gt;, so persistent connections actually get reset — stands at &lt;strong&gt;21 to nothing&lt;/strong&gt; with 3 abstentions. Alexander Kurilo arrived after the discussion phase to ask for an opt-in instead, warning that on older databases persistent connections will silently turn non-persistent. Eric noted: "MySQL 5.7.3 is at least a decade old; it was released on December 3rd, 2013." After walking through every opt-out design he could think of, he concluded the right move is to make the correct behavior the default. The 3 no votes on autoconf include Jakub Zelenka, who's worried about building on Red Hat Enterprise Linux 8 and 9 — Tim offered to delay that particular merge to early &lt;code&gt;8.7&lt;/code&gt;. Both votes close July 30.&lt;/p&gt;

&lt;p&gt;Saturday night, Pierre Joye opened the RFC that grew out of the libgd sync we covered last week: &lt;strong&gt;&lt;code&gt;gd&lt;/code&gt; 2.4&lt;/strong&gt;. It's big — 3 pillars. First, syncing the bundled &lt;code&gt;gd&lt;/code&gt; extension with upstream libgd: new codecs like QOI, JPEG XL, and UltraHDR, animated GIF and WebP support, multi-page TIFF, and real metadata handling. Second, an additive object-oriented &lt;code&gt;Gd\&lt;/code&gt; API — codecs with &lt;code&gt;fromFile()&lt;/code&gt; and &lt;code&gt;toStream()&lt;/code&gt;, immutable image info, streaming readers and writers. Third, a brand-new &lt;strong&gt;2D vector canvas&lt;/strong&gt; built on FreeType's rasterizer, with gradients and the full Cairo compositing set. He says the implementation is nearly done, including a security audit. He declared discussion open for 14 days, until August 1 — and that one sentence is where the trouble started.&lt;/p&gt;

&lt;p&gt;Because August 1 plus a 14-day vote lands &lt;em&gt;after&lt;/em&gt; the deadline. Release manager Matteo Beccati was gentle about it, writing: "As much as I like this RFC, I'm afraid it came in a little too late." Jakub Zelenka explained that nobody — release managers included — has the authority to grant an exception; that would take a change to the policy itself. And Rowan Tommins did the arithmetic: with alpha 1 out July 2, the cutoff for an RFC's final state was July 14, which is 4 days before this thread even opened. Pierre's frustration has a specific shape. The implementation was finished weeks ago — what delayed everything was that his pull request sat waiting on an approval that had been assigned to an automated bot reviewer, so no human was ever going to sign off, and he eventually merged it himself. He also argues the stakes are real, because PHP 9 is the one chance to change old defaults, and missing this window locks the current design in for years. The thread got tense over tone along the way — Pierre felt brushed off by a terse reply, and Rowan apologized outright, then made the counter-case that a fixed cutoff applied to everyone is fairer than debating each RFC's merits one at a time. All of this landed the same day Larry Garfield asked the list, in a separate thread, to hold new business until September 1 so reviewers can focus on &lt;code&gt;8.6&lt;/code&gt;'s finish line. So &lt;code&gt;gd&lt;/code&gt; 2.4 is alive and under discussion — just aimed at the &lt;em&gt;next&lt;/em&gt; release, whatever its number turns out to be.&lt;/p&gt;

&lt;p&gt;Caleb White's pipe assignment operator, &lt;code&gt;|&amp;gt;=&lt;/code&gt;, had a crowded week. Larry Garfield opened it unable to find a compelling use case, and by Monday had moved to a no — pushed there, he says, by a competing proposal. That competing proposal is Vadim Dvorovenko's &lt;strong&gt;left-to-right assignment&lt;/strong&gt; RFC, published Sunday, which claims the &lt;em&gt;same&lt;/em&gt; &lt;code&gt;|&amp;gt;=&lt;/code&gt; token with opposite semantics. Vadim objects on principle, arguing: "Attempting to transform such an operator from an immutable, functional construct into a mutable, imperative one steers the language in the wrong direction and undoes previous efforts." Caleb declined to merge the proposals, noting that F#, Elixir, OCaml, and Hack all kept ordinary assignment alongside their pipes. Larry also claimed none of the pipe proposals could make &lt;code&gt;8.6&lt;/code&gt;, and Tim Düsterhus corrected him, asserting: "This is false" — the last major change was July 13, so voting could open July 27 and close August 10, before the freeze. Meanwhile Bob Weinand asked whether the desugaring double-fires property hooks. Caleb came back with tests showing &lt;code&gt;|&amp;gt;=&lt;/code&gt; behaves exactly like &lt;code&gt;??=&lt;/code&gt;, and updated the RFC's single-evaluation section to match. Vadim's own RFC, as of recording, has &lt;strong&gt;0&lt;/strong&gt; replies.&lt;/p&gt;

&lt;p&gt;Paul M. Jones's &lt;code&gt;strict-namespace&lt;/code&gt; RFC — the piece he carved out of function autoloading last Tuesday night — spent its first full week in one long argument about a single word. Rowan Tommins objected first, writing that strict "implies some extra check that namespaces are [correct] in some way, which isn't really what this is about." Ilija Tovilo went deeper, arguing: "the value-add of this declaration is very small if the plan isn't ever to deprecate/remove the old behavior." Tim Düsterhus is &lt;strong&gt;in favor&lt;/strong&gt; — with a rename to &lt;code&gt;global_fallback=0&lt;/code&gt;. By Friday Paul had 4 candidate names on the table and a diagnosis: the pushback is the name, not the feature. Theodore Brown pointed out he'd floated the same directive in 2019; Paul added it to the prior art with an apology. And Benjamin Außenhofer suggested splitting the ballot — vote the concept, then vote the name. Rowan warned against it, writing: "a split vote leaves voters who actively dislike a particular name with an awkward choice: vote Yes, and risk the [bad] name being chosen; or vote No, even though you would support the feature under a different name." The rest of the autoloading corner kept moving too: Paul updated &lt;strong&gt;function autoloading&lt;/strong&gt; mark 5 to lean on the new RFC and wants its vote open in about 2 weeks, and Michael Morris's improved-autoloading draft drew warm-but-firm feedback from Larry Garfield and Rowan Tommins — both like the namespace-setup-file idea, neither wants it crammed into the class autoloader's callback.&lt;/p&gt;

&lt;p&gt;Nicolas Grekas didn't let Ilija Tovilo's "sadly not in favor" be the last word on &lt;strong&gt;serializable closures&lt;/strong&gt;. His rebuttal: caching one attribute isn't the point — the point is skipping the &lt;em&gt;entire&lt;/em&gt; metadata pipeline that frameworks re-run on every request, and that's the measured slow path. On the security design, he refused to loosen it, writing: "Name-based closure unserialization would ship a universal, app-independent gadget in the engine ... I won't commit to an RFC that turns every serialized payload into that kind of gadget, and I don't think we should, either." Then Saturday brought version &lt;code&gt;0.3&lt;/code&gt;, and a surgical cut — the reflection API is gone, the &lt;code&gt;serialize()&lt;/code&gt; support stays. His reasoning: "serialize() is the one feature that most/all cache systems are built on, so that's the place that needs the improvement." Fresh reviews welcome.&lt;/p&gt;

&lt;p&gt;Wendell Adriel came back to the list Thursday proposing &lt;strong&gt;typed array declarations&lt;/strong&gt; — &lt;code&gt;array&amp;lt;int, string&amp;gt;&lt;/code&gt; as real syntax, with 3 escalating enforcement levels. The review was fast and unsparing. Lazare Inepologlou flagged that you can't soundly subtype a mutable array without splitting reads from writes, and Wendell shipped a revised draft the &lt;em&gt;next day&lt;/em&gt;. Rob Landers warned the whole thing overlaps the reified generics work, on hold until after the freeze, which is late August at the earliest. Rowan Tommins noted that level 1 — syntax without enforcement — rhymes with the bound-erased generics RFC the list just declined. Michał Marcin Brzuchalski even found a runtime hole, where functions like &lt;code&gt;parse_str()&lt;/code&gt; that build results directly into a typed property can dodge the check. By Monday, Wendell put the RFC on hold himself. Larry Garfield's verdict was the sharpest, calling this "the already-dangerously-overloaded array mega-type" and asking for real typed list, set, and dictionary objects instead — which Wendell promptly volunteered to help build.&lt;/p&gt;

&lt;p&gt;The frozen &lt;strong&gt;deprecations&lt;/strong&gt; list for PHP &lt;code&gt;8.6&lt;/code&gt; got its evidence file. Juliette Reinders Folmer scanned the Packagist Top 4-thousand — nearly four hundred fifty thousand files — and posted counts for every proposal. The headline &lt;strong&gt;being&lt;/strong&gt;: &lt;code&gt;list()&lt;/code&gt; appears over &lt;strong&gt;twelve thousand&lt;/strong&gt; times, and Juliette wrote plainly: "Having said that, I'm definitely not in favour of deprecating list()." Compare &lt;code&gt;spl_object_hash()&lt;/code&gt; at 625, &lt;code&gt;is_integer()&lt;/code&gt; at 303, and a long tail of single and double digits — several proposals scored a clean 0. Kamil Tekiela discovered his mysqli proposal had missed the procedural &lt;code&gt;mysqli_stmt_init()&lt;/code&gt;, patched the text, and worried aloud: "I hope this change is not going to reset the counter." Tim Düsterhus was quick to correct the record downward — one scary-looking count, on &lt;code&gt;_&lt;/code&gt; as a constant, collapses to 0 once false positives come out. And Monday, right on schedule, Gina P. Banyard confirmed the timetable, writing: "I intend to open the vote next Monday (the 27th of July) for 2 weeks so that the vote is finished on time for 8.6." Every deprecation gets voted in isolation — bring a lunch.&lt;/p&gt;

&lt;p&gt;Quick hits. Go Kudo returned with a rebuilt cache proposal — a bundled &lt;code&gt;user_cache&lt;/code&gt; extension, fully decoupled from OPcache this time; Larry Garfield likes it, flagged the lock story around &lt;code&gt;remember()&lt;/code&gt;, and gently redirected it to &lt;code&gt;8.7&lt;/code&gt; — adding: "Or 9, if that's what we call it." Holly Schilling's &lt;strong&gt;4x&lt;/strong&gt; fix for non-public asymmetric setters got its answer: no RFC needed — Tim confirmed a pure performance improvement just needs PR review, and Ilia Alshanetsky called it "definitely a strong candidate for PHP 8.6 inclusion." &lt;strong&gt;fennic&lt;/strong&gt; pitched engine-native PSR-4 autoloading with &lt;code&gt;spl_autoload_psr4_register()&lt;/code&gt;; Alex Rock wants classmap support before it can replace Composer's bootstrap, and Heinz Wiesinger pointed to his existing PECL extension doing much the same. Edmond of the TrueAsync project published a pre-RFC for an &lt;strong&gt;async scheduler&lt;/strong&gt; engine interface — coroutine-aware core, no scheduler in core itself. His philosophical problem is that the RFC has &lt;em&gt;no&lt;/em&gt; user-visible changes at all, and so far it has 0 replies. And Osama Aldemeery asked for RFC karma to formalize &lt;code&gt;PREG_THROW_ON_ERROR&lt;/code&gt; — Ilija Tovilo granted it &lt;strong&gt;2 minutes&lt;/strong&gt; later.&lt;/p&gt;

&lt;p&gt;Liam Hammett's markup expressions thread sprouted an alternative: Edmond proposed making the &lt;em&gt;parser&lt;/em&gt; extensible instead, so JSX-like syntaxes could ship as extensions — Morgan liked that better than blessing one syntax, and within a day Edmond had a working DSL-hooks prototype, announcing: "Your wish has been granted. 🙂" Máté Kocsis and Ignace Nyamagana Butera kept refining &lt;strong&gt;query parameters&lt;/strong&gt; — the open question is whether parsing limits belong on builder methods too, with Ignace arguing PHP shouldn't police what's really a business constraint. Prateek Bhujel's terminal-helpers extension hit &lt;code&gt;0.6.0&lt;/code&gt; — it's now installable via PIE, and its output methods now write to standard PHP streams like STDOUT and STDERR instead of only its own built-in targets. The ballot queue grew by 2: Nick Sdot posted intent to vote on &lt;strong&gt;readonly property defaults&lt;/strong&gt; for on or around July 23, and Khaled Alam's const-object-property-write opens Saturday the 25th — both aiming ahead of the freeze. Ben Ramsey amended the &lt;strong&gt;Working Groups&lt;/strong&gt; RFC with a new section setting expectations for charter-RFC discussion. And release week: PHP &lt;code&gt;8.6.0alpha2&lt;/code&gt;, &lt;code&gt;8.5.9RC1&lt;/code&gt;, and &lt;code&gt;8.4.24RC1&lt;/code&gt; all shipped — with alpha 3 and both GA releases converging on July 30 — while the release managers posted the countdown that framed half of this episode: soft feature freeze August 11, beta 1 August 13, every &lt;code&gt;8.6&lt;/code&gt; vote closed before then.&lt;/p&gt;

&lt;p&gt;So that's the week: 2 ballot boxes open and both lopsided — &lt;code&gt;Duration&lt;/code&gt; cruising at 23 to 1, minimum versions right behind it; &lt;code&gt;gd&lt;/code&gt; 2.4 arriving 4 days after the door closed and pointing at the next release instead; a pipe operator with 2 authors claiming 1 token; typed arrays proposed, revised, and shelved inside 5 days; and the deprecations list armed with its evidence file, ballots opening Monday — with readonly defaults and const-property-write queued right behind. Links to every thread are below. Thanks again to &lt;code&gt;Tideways.com&lt;/code&gt; for supporting this week's episode. We're Artisan Build. See you next week.&lt;/p&gt;

</description>
      <category>php</category>
      <category>laravel</category>
      <category>news</category>
      <category>webdev</category>
    </item>
    <item>
      <title>This Week In PHP Internals | July 15, 2026</title>
      <dc:creator>Len Woodward</dc:creator>
      <pubDate>Thu, 16 Jul 2026 00:50:01 +0000</pubDate>
      <link>https://dev.to/projektgopher/this-week-in-php-internals-july-15-2026-4nhb</link>
      <guid>https://dev.to/projektgopher/this-week-in-php-internals-july-15-2026-4nhb</guid>
      <description>&lt;p&gt;Hello world, it's Wednesday, July 15, 2026, and here's what happened This Week in PHP Internals.&lt;/p&gt;

&lt;p&gt;This week's episode is brought to you by &lt;strong&gt;Tideways&lt;/strong&gt;. Something in production is slow — and you can't see &lt;em&gt;where&lt;/em&gt;. Tideways takes PHP developers from slow request to root cause in minutes, with profiling, tracing, and monitoring built specifically for PHP. 5-minute install, no credit card. Start your free trial at &lt;code&gt;tideways.com&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;This week's top story is a brand-new keyword knocking on the door: &lt;code&gt;extension&lt;/code&gt;. One week after Larry Garfield floated Kotlin-style extension functions at the scalar-methods RFC, Holly Schilling arrived with working prototypes of Swift-style &lt;strong&gt;class extensions&lt;/strong&gt; — born, she says, out of a Discord conversation — and it became the biggest thread of the week at 26 messages. The idea: add methods to a class you don't own — &lt;code&gt;extension \DateTimeImmutable&lt;/code&gt; gives every date an &lt;code&gt;isWeekend()&lt;/code&gt; — and, in a later phase, put methods on scalars, so &lt;code&gt;"hello"&lt;/code&gt; gets a &lt;code&gt;length()&lt;/code&gt;. She published 3 draft RFCs as gists, implementation included. Michael Morris asked the obvious first question, writing: "Looking at Swift's extension syntax I fail to see anything it adds not covered by the above." — the above being inheritance and traits. Holly drew the line clean: "An extension is essentially the reverse of a trait." With a trait, the &lt;strong&gt;author&lt;/strong&gt; of the class decides; with an extension, the &lt;em&gt;user&lt;/em&gt; of the class decides.&lt;/p&gt;

&lt;p&gt;Then came the twist. 2 days in, Holly sat down to defend her own scalar-methods implementation — and couldn't. She wrote: "Typing this email this morning gave me real hesitation. If I can’t support my own implementation, no one else should either. I immediately set out to build a better version that I could put my full weight behind." The better version came from an unexpected place: &lt;strong&gt;C# 14&lt;/strong&gt;, whose new extension syntax puts the receiver right in the declaration — &lt;code&gt;extension string $str&lt;/code&gt; — no autoboxing, no downcast headaches. She rewrote all 3 drafts and the implementation around it in a day. Not everything got absorbed so gracefully: when Alex Rock proposed an explicit &lt;code&gt;extend ... with ...&lt;/code&gt; wiring statement, Holly apologized in advance for the bluntness, then answered: "I reject this functionality." — extensions stay file-scoped, and they &lt;strong&gt;never&lt;/strong&gt; override a real method. And Pierre Joye flagged a process problem: proposals keep citing Discord conversations as their origin, while he reads only internals and GitHub — and found no reference to a php.net Discord anywhere he searched.&lt;/p&gt;

&lt;p&gt;Gina P. Banyard's &lt;strong&gt;Deprecations for PHP &lt;code&gt;8.6&lt;/code&gt;&lt;/strong&gt; — the annual bundle that spent June on fire — reached its quiet milestone: the list is locked. Gina declared the RFC "frozen", with only minor amendments still allowed, and put dates on everything: "I will initiate a call to vote next week on Monday (the 20th) for the following Monday (the 27th) so that the vote is done by the 10th of August." Because items were still being added in the final week, the policy's 2-week discussion clock is what sets that gap — and the timing is deliberate, so accepted proposals can land in &lt;code&gt;8.6.0&lt;/code&gt; &lt;strong&gt;beta 1&lt;/strong&gt;. The week's lightest subplot: Garrett W. wants the deprecation notices themselves copy-edited — those commas are comma &lt;em&gt;splices&lt;/em&gt;, and he'd use semicolons. Tim Düsterhus explained the house style comes from PHP error messages, and added: "The deprecation messages can still change during PR review (or even later), there is explicitly no BC guarantees for those."&lt;/p&gt;

&lt;p&gt;Paul M. Jones's &lt;strong&gt;function autoloading&lt;/strong&gt; — attempt number 5 — got smaller this week, on purpose. The &lt;code&gt;declare(strict_namespace=1)&lt;/code&gt; directive he added last week drew a structural objection from Tim Düsterhus, who argued: "I believe the strict_namespace=1 directive is a sufficiently unrelated concern - with enormous bikeshedding potential on its own, but also sufficient usefulness on its own - such that I feel it should be its own RFC that is a prerequisite to this one. It should not be piggy-backed onto function autoloading." Paul didn't fight it. He replied: "I'm good with that. I'll prepare a separate RFC and remove that from the function-autoloading one." — and by Tuesday night it existed: &lt;code&gt;strict-namespace&lt;/code&gt; is now its own RFC on the wiki, and mark 5 will reference it instead of carrying it. Tim also showed his cards: he built the &lt;em&gt;inverse&lt;/em&gt; directive as an experiment a year ago, and he's firmly on team fully-qualify-everything.&lt;/p&gt;

&lt;p&gt;Tim Düsterhus and Derick Rethans' &lt;code&gt;Time\Duration&lt;/code&gt; class is days from the ballot box — and it picked up its first declared no. Pierre Joye spent the week pressing on &lt;code&gt;fromSeconds()&lt;/code&gt; and its capped nanoseconds argument, and landed here: "I like that RFC, but it adds confusions and limitations from what is supposed to be a simple first step. As it stands now, despite the fact that I would love to see it, I tend towards a no." Tim's defense reached for the stopwatch — it's natural, he argued, to say Usain Bolt broke the 100 m world record with "9 seconds 58 hundreths" — exactly the fixed-point form &lt;code&gt;fromSeconds()&lt;/code&gt; uses. Pierre countered: "It is just as common in the real world to have duration information in one unit only and decimal. F.e. 234.54ms. or 3.4 hours, etc." Neither moved — and per Tim, that's fine: "All discussions have been resolved (some of them with an “agree to disagree”), so we plan to open voting at the end of this or early next week." The 14-day cooldown runs out Friday evening, European time.&lt;/p&gt;

&lt;p&gt;A first-time author had a very good week. Caleb White got RFC karma from Ilija Tovilo, and his first proposal — the &lt;strong&gt;pipe assignment operator&lt;/strong&gt;, &lt;code&gt;|&amp;gt;=&lt;/code&gt; — went through review polish at speed. The idea: &lt;code&gt;$x |&amp;gt;= trim(...)&lt;/code&gt; pipes &lt;code&gt;$x&lt;/code&gt; through and puts the result back, just like every other modify-assign operator. Tim Düsterhus liked the shape, saying: "Conceptionally I like the idea of having an “in-place modification operator” for function calls and the semantics of the operator seem to be consistent with the existing “modify-assign” operators we have, particularly also with regard to operand order. Nice idea!" Tim also caught a precedence claim that was &lt;em&gt;almost&lt;/em&gt; right — assignment operators are not the lowest; the infamous &lt;code&gt;or die()&lt;/code&gt; pattern depends on it — and Caleb fixed the RFC the same day, both times. The list's real energy went to naming. Ben Ramsey offered: "I like to think of |&amp;gt; as the volcano operator, while |&amp;gt;= is the erupting volcano operator."&lt;/p&gt;

&lt;p&gt;Then last night — hours before we hit record — Liam Hammett published &lt;strong&gt;Native Markup Expressions&lt;/strong&gt;: JSX-style markup as first-class PHP expressions. Write a &lt;code&gt;&amp;lt;button&amp;gt;&lt;/code&gt; tag straight into an expression, and it compiles to &lt;code&gt;new \Markup\Element(...)&lt;/code&gt; — escaped by default, with capitalized tags becoming components. Liam headed off the obvious reading, writing: "Despite appearances, this is not a template language grafted onto the engine - the syntax is pure compile-time sugar." First reviewer Garrett W. questioned that capitalization heuristic — PSR-4 isn't binding, and lowercase class names are legal. Liam pushed back: "Fallback resolution turns typos into silent bugs. With the capitalisation rule,  fails loudly with a class-not-found error. With fallback resolution, it silently renders as a literal  element and you find out in the browser, if you find out at all." This is the &lt;em&gt;ambitious&lt;/em&gt; RFC Liam requested wiki karma for on July 10 — Ilija Tovilo granted it Monday: "RFC karma was granted. Good luck!"&lt;/p&gt;

&lt;p&gt;Marc Henderkes wants to end PHP's double life. His pre-RFC: make &lt;strong&gt;ZTS&lt;/strong&gt; — the thread-safe build — the default, deprecate the rest, and drop NTS entirely in PHP 9. He summed it up himself: "Tl;dr: nobody wants to maintain two builds and even having a necessary split is making things hard." Distros package only NTS, FrankenPHP needs ZTS, and php-src carries roughly 420 ZTS ifdefs. The performance tax is dissolving too — his numbers: "Worst case performance cost of ZTS in php 8.5 was ~5%, will be ~1.5% in php 8.6, likely ~0.5% after my last open PRs." To be clear, he is &lt;em&gt;not&lt;/em&gt; proposing to deprecate FPM — a single-threaded ZTS run keeps everything NTS does today. 2 of the named blockers — the arm64 macOS JIT and the fuzzer SAPI — were fixed within 2 days of the thread opening; the third, NewRelic's missing ZTS support, isn't Marc's to fix. Benjamin Eberlei backed the initiative, Calvin Buckley volunteered his own PHP distribution as a test subject, and Marc has requested wiki karma to write the full RFC.&lt;/p&gt;

&lt;p&gt;Nicolas Grekas's &lt;strong&gt;serializable closures&lt;/strong&gt; spent the week absorbing a deep review from Tim Düsterhus — and then ran into a wall. Tim was candid: "While reading the RFC initially and now the updated version, I got the feeling that it was “overfitted” to solve the specific use case and deployment scenario that you consider a “best practice”, which I feel results in “weird” behavior when one leaves that happy path." Still, the 2 converged on real changes: Nicolas adopted Tim's tagged-union serialization format, and — after an off-list suggestion from Arnaud — replaced the fragile line-number check with a compile-time &lt;strong&gt;hash of the closure body&lt;/strong&gt;, so a shifted &lt;code&gt;use&lt;/code&gt; import can't silently break payloads. Then Tuesday night, Ilija Tovilo weighed in against — questioning whether attributes need caching at all, and finding the format and implementation too complex. He closed with: "Overall, I'm sadly not in favor of this RFC."&lt;/p&gt;

&lt;p&gt;No ballot box was open this week — instead, the queue got dates. Eric Norris's &lt;strong&gt;minimum supported versions&lt;/strong&gt; opens voting &lt;em&gt;tomorrow&lt;/em&gt;, July 16 — the earliest the policy allows. &lt;code&gt;Duration&lt;/code&gt; clears its cooldown Friday evening and opens late this week or early next. The deprecations list calls its vote Monday the 20th, with ballots open the 27th. And Khaled Alam's const-object-property-write RFC is cleared to open July 25 — no later than the 28th to make &lt;code&gt;8.6&lt;/code&gt;. All of it backs into the release managers' reminder from Monday. Matteo Beccati wrote: "Any RFC intended for inclusion in PHP 8.6 must have its discussion concluded and its voting closed before August 13." Soft feature freeze: August 11. Beta 1: August 13.&lt;/p&gt;

&lt;p&gt;Quick hits, round 1. Máté Kocsis revived his &lt;strong&gt;query parameters&lt;/strong&gt; RFC with a simplification: he's cutting the array API down to 2 — &lt;em&gt;maybe&lt;/em&gt; 3 — methods, &lt;code&gt;fromArray()&lt;/code&gt; and &lt;code&gt;toArray()&lt;/code&gt; with &lt;code&gt;withArray()&lt;/code&gt; on the bubble, plus an options class with security limits on parsing; League-of-URI maintainer Ignace Nyamagana Butera answered with naming notes and an enum for null handling. Nick Sdot's readonly-property defaults — &lt;em&gt;zero&lt;/em&gt; replies when we covered it last week — got its replies: Tim Düsterhus found an unserialization wrinkle, Nick fixed it the same day, Larry Garfield is skeptical, and Tim plans to abstain. Holly Schilling — the same Holly Schilling from our top story — found that non-public asymmetric setters run roughly &lt;strong&gt;4x&lt;/strong&gt; slower than public ones, posted a fix, and then a formal RFC for it — with Ilija Tovilo reviewing the PR, she's giving the list a few days to weigh in on &lt;code&gt;8.6&lt;/code&gt; versus waiting; Marc Henderkes and Calvin Buckley both questioned whether an internal change needs an RFC at all. And Osama Aldemeery's &lt;code&gt;PREG_THROW_ON_ERROR&lt;/code&gt; settled its naming on Tim's advice: an unnamespaced &lt;code&gt;PregException&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;Round 2. Sjoerd Langkemper showed that newlines in &lt;code&gt;CURLOPT_HTTPHEADER&lt;/code&gt; values inject extra headers — even over HTTP/2 — and opened a fix; upstream curl is adding its own check, and curl's own Daniel Stenberg confirmed CRLF is disallowed. Xavier Leune bumped his curl socket-callbacks PR — pitching it as the missing tool against SSRF to localhost — and is still waiting on a reply. The bundled-GD sync to libgd &lt;code&gt;2.4&lt;/code&gt; drew its first pushback: Giovanni Giacobbi says the upstream code is too young and &lt;code&gt;8.6&lt;/code&gt; too far along, while Pierre Joye, Jakub Zelenka, and Ilia Alshanetsky want it landed before beta 1 — Jakub's condition being that the security-review findings get addressed first — and Kamil Tekiela says wait for the next version. And the DTLS experiment in the &lt;code&gt;openssl&lt;/code&gt; extension became a real draft PR; Jakub Zelenka confirmed the direction and is already sketching the generalization it needs.&lt;/p&gt;

&lt;p&gt;So that's the week: a brand-new &lt;code&gt;extension&lt;/code&gt; keyword that rewrote itself mid-thread; a frozen deprecations list with ballots set for the 27th; function autoloading shedding a prerequisite RFC; a &lt;code&gt;Duration&lt;/code&gt; vote opening within days, carrying its first declared no; and a JSX-flavored surprise landing the night before we filmed. Nothing was voted on this week — and the ballot queue starts moving tomorrow. Links to every thread are below. Thanks again to &lt;code&gt;Tideways.com&lt;/code&gt; for supporting this week's episode. We're Artisan Build. See you next week.&lt;/p&gt;

</description>
      <category>php</category>
      <category>laravel</category>
      <category>news</category>
      <category>webdev</category>
    </item>
    <item>
      <title>This Week In PHP Internals | July 8, 2026</title>
      <dc:creator>Len Woodward</dc:creator>
      <pubDate>Thu, 09 Jul 2026 01:05:45 +0000</pubDate>
      <link>https://dev.to/projektgopher/this-week-in-php-internals-july-8-2026-100f</link>
      <guid>https://dev.to/projektgopher/this-week-in-php-internals-july-8-2026-100f</guid>
      <description>&lt;p&gt;Hello world, it's Wednesday, July 8, 2026, and here's what happened This Week in PHP Internals.&lt;/p&gt;

&lt;p&gt;This week's episode is brought to you by &lt;strong&gt;Ballast&lt;/strong&gt;. Your team ships constantly — but how much of that work actually &lt;em&gt;lasts&lt;/em&gt;? Ballast reads your git history and computes a deterministic &lt;strong&gt;durability score&lt;/strong&gt;: does shipped code hold up, or churn and get redone? Ballast is in early access now at &lt;code&gt;ballast.now&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;This week's top story is still Gina P. Banyard's &lt;strong&gt;Deprecations for PHP &lt;code&gt;8.6&lt;/code&gt;&lt;/strong&gt; — the annual bundle where every removal gets its own ballot — and this week it caught fire &lt;em&gt;twice&lt;/em&gt;. First fire: the long-array question. With Seifeddine Gmati's &lt;code&gt;list()&lt;/code&gt; deprecation already on the table, Tim Düsterhus floated a draft that turns &lt;code&gt;array()&lt;/code&gt; into a real cast function — and Michael Morris erupted at where that road leads. He asked, "Are you crazy?" — deprecating &lt;code&gt;array()&lt;/code&gt; would, by his math, touch 3 quarters of WordPress core and nearly every plugin. Seif's counter was all receipts: the rewrite is one &lt;code&gt;ast-grep&lt;/code&gt; command, &lt;code&gt;array(...)&lt;/code&gt; and &lt;code&gt;[...]&lt;/code&gt; compile to &lt;strong&gt;byte-identical opcodes&lt;/strong&gt; — and, for the record, "The proposal is to deprecate list(), not array()." Then Juliette Reinders Folmer — who maintains the WordPress Coding Standards — corrected &lt;em&gt;everyone&lt;/em&gt;: WordPress still supports PHP &lt;code&gt;7.4&lt;/code&gt;, and short arrays were blocked there for years by a handful of core committers, not the community.&lt;/p&gt;

&lt;p&gt;It got personal — Morris told Seif to step out of his ivory tower; Seif kept answering with engineering. He wrote: "I've written a compiler that migrated a multi-million-line codebase from one language to another, automatically, overnight. Swapping one AST node for another that is literally equivalent to the compiler is not a feat of engineering courage." To Morris's credit, when told he was turning it personal, he replied: "I am, and I apologize." — and the thread cooled.&lt;/p&gt;

&lt;p&gt;Then Monday it reignited — over &lt;strong&gt;evidence&lt;/strong&gt;. Gina regrouped the list, folded in new items sent to her directly, and set the clock: "If none are added or amended, I will initiate a call to vote next week." Rowan Tommins counted 35 proposals and only 8 with any discussion of who'd be affected, and threatened to cast 27 blanket no votes. Gina drew her line: "You are free to do as you please." — she won't produce &lt;em&gt;metrics for the sake of metrics&lt;/em&gt; without an agreed method. Rowan held firm: "I do not think we should be removing features without thinking about who will be affected. I'm honestly shocked that that's a controversial opinion". Juliette, once again the bridge, renewed her offer to generate real impact data with PHPCompatibility — feasible, she says, for about 25 of the 36 items. One item is on its way out: the by-reference-return-modifier deprecation — Bob Weinand recommended a complete retraction, and its proposer had already offered one. The RFC freezes &lt;strong&gt;July 13&lt;/strong&gt; — expect the call to vote next week, though with the mandatory 14-day cooldown after Gina's latest changes, actual ballots open &lt;strong&gt;July 21&lt;/strong&gt; at the earliest.&lt;/p&gt;

&lt;p&gt;Tim Düsterhus and Derick Rethans' &lt;code&gt;Time\Duration&lt;/code&gt; class — the stopwatch value object aimed at &lt;code&gt;8.6&lt;/code&gt; — got called &lt;strong&gt;done&lt;/strong&gt; this week: "we would consider the RFC to be complete". The final decisions: &lt;code&gt;add&lt;/code&gt; and &lt;code&gt;sub&lt;/code&gt; won an informal PHP Foundation Slack poll &lt;em&gt;unanimously&lt;/em&gt;; the past-tense method suffixes are gone; &lt;code&gt;divideInto()&lt;/code&gt; got pushed to future scope; and the ban on negative constructor arguments stays, on Derick's call. One naming question goes to the voters as a secondary vote: full names like &lt;code&gt;multiplyBy&lt;/code&gt; and &lt;code&gt;absolute&lt;/code&gt;, or abbreviations like &lt;code&gt;mul&lt;/code&gt; and &lt;code&gt;abs&lt;/code&gt; — with the abbreviations needing a 2-thirds supermajority.&lt;/p&gt;

&lt;p&gt;But one fight would &lt;em&gt;not&lt;/em&gt; close: &lt;code&gt;fromSeconds()&lt;/code&gt;. It takes seconds &lt;strong&gt;plus&lt;/strong&gt; a nanoseconds argument, capped at 999 million 999 thousand 999 — overflow is rejected, not carried. Marc B. objected: "It makes it simple to reason about for you as implementing it - it forces the burden to the one using the API." Pierre Joye brought prior art: Java and Rust both carry the overflow instead of rejecting it, and JavaScript's Temporal doesn't impose the cap either. Tim's defense: an injective constructor means one value, one spelling — a form asking for seconds should reject out-of-range input the same way June 31 should be rejected, not silently become July 1. Neither side budged — and with the RFC complete, that question rides along to the vote.&lt;/p&gt;

&lt;p&gt;Function autoloading now has &lt;strong&gt;2 competing designs&lt;/strong&gt;, and they met in the same inbox on the same day. Paul M. Jones updated his mark-5 RFC — that's attempt number 5 — adding a &lt;code&gt;declare(strict_namespace=1)&lt;/code&gt; directive to kill the global-fallback edge case, plus research across the top 1000 Packagist packages: exactly &lt;strong&gt;2&lt;/strong&gt; packages and 8 call sites would misbehave. Meanwhile, Michael Morris — fresh off the deprecations thread — had floated an idea on July 2, saying: "An idea that popped into my head an hour ago, that I don't have another PHP Dev to talk to about, what if you could register a function that is called by PHP the first time it sees a namespace declared?" Five days later that spitball was a formal draft: autoloader callbacks that take &lt;strong&gt;2 arguments&lt;/strong&gt; — the class &lt;em&gt;and&lt;/em&gt; the namespace — firing the first time the engine meets a namespace. And within hours of Paul's update, Morris was in Paul's thread advertising his rival.&lt;/p&gt;

&lt;p&gt;The reason the spitball grew legs is Rowan Tommins. His endorsement became the backbone of Morris's draft — he wrote: "This really nicely side-steps the global-vs-namespace sequence problem that function autoloading always runs into: by the time the engine reaches an unqualified name, the namespace loader has already run for the current namespace, and defined any functions it wants." Not everyone's sold. Aleksander Machniak flagged that passing &lt;code&gt;null&lt;/code&gt; to existing string-typed autoloaders is itself a BC break, and Alex Rock argued the draft bundles 2 different proposals and called it overkill. Morris's reply had some edge: "And you've misread the proposal entirely."&lt;/p&gt;

&lt;p&gt;The busiest brand-new thread: Matheus Martins revived &lt;strong&gt;typed closures&lt;/strong&gt; — write &lt;code&gt;Closure(int): bool&lt;/code&gt; as a parameter type, and a mismatched callback fails at the boundary with a clean TypeError instead of exploding deep inside your &lt;code&gt;filter()&lt;/code&gt;. The reception was warm — Matthew Weier O'Phinney would find it "very useful", and Larry Garfield is in favor, &lt;em&gt;to nobody's surprise&lt;/em&gt;. Rob Landers suggested waiting for generics; Seif pointed out that would need variadic generics, which have never appeared in &lt;strong&gt;any&lt;/strong&gt; proposal — waiting for generics means waiting indefinitely. Larry was blunter: "Generics syntax is the wrong format to use for this, full stop." The real villain is the &lt;em&gt;lexer&lt;/em&gt;: inside &lt;code&gt;Closure(int)&lt;/code&gt;, that &lt;code&gt;(int)&lt;/code&gt; is a &lt;strong&gt;cast token&lt;/strong&gt;. Osama Aldemeery, who's been down this exact tunnel, put it memorably: "So the natural spelling is, unfortunately, the engine-hostile one."&lt;/p&gt;

&lt;p&gt;Where it landed: inline signatures first, named type-aliases later, and neither blocks the other. Larry pre-empted the objection everyone could see coming — if someone gets fussy about long signatures, the answer should be "that's nice, go work on aliases then and don't block this RFC". By Monday he'd added just one ask: invokable objects should fit through the same door, not get squeezed through closures.&lt;/p&gt;

&lt;p&gt;Rob Landers' &lt;strong&gt;primary constructors&lt;/strong&gt; — the constructor hoisted onto the class line — spent June fighting over whether it may carry a body. This week that fight hit its endgame, in a single day of posts. Rowan Tommins came off the fence — with a body bolted on, he'd be a definite &lt;strong&gt;no&lt;/strong&gt;. Rob, the author, declined to relitigate: "All I can say is that I reject it for future scope, repeatedly." Nick Sdot stood down under protest, warning: "We don't need more half finished, half not working, confusing features in PHP." And then, quietly, the week's one unreserved fan — a reader who wrote that extending third-party classes and calling the parent constructor by hand "always felt dirty". The thread's been silent since July 1.&lt;/p&gt;

&lt;p&gt;Michal Kral's &lt;strong&gt;scalar object methods&lt;/strong&gt; — &lt;code&gt;(3)-&amp;gt;pow(2)&lt;/code&gt;, dispatched at compile time — came back for round 2, and the room steered it somewhere new. Michal gave real ground: he'd restrict or drop the file-order-dependent form, and lean on typed locals for safety. Seif stayed unmoved, arguing: "Seeing $s-&amp;gt;trim() where $s is a string, I should know it works. A construct where identical AST dispatches or doesn't depending on file position, a redundant cast, or whether a declaration sits above or below the call is not something people can reason about." Then Larry Garfield reframed the whole conversation: a &lt;em&gt;small curated set&lt;/em&gt; of methods, he said, "is bikeshed bait, and needlessly limiting" — and counter-pitched Kotlin-style &lt;strong&gt;extension functions&lt;/strong&gt; on any type, from a design he drafted with Sara Golemon. Michal's response? &lt;em&gt;Genuinely interested.&lt;/em&gt; They're talking off-list once Larry's back from vacation.&lt;/p&gt;

&lt;p&gt;To the scoreboard — one ballot closed, one never opened. Jordi Kroon's &lt;strong&gt;third-party extension documentation&lt;/strong&gt; RFC is &lt;em&gt;in&lt;/em&gt;: 26 to 1, with 1 abstention. The secondaries settled too: the docs land on a &lt;code&gt;php.net&lt;/code&gt; subpath rather than a new subdomain, 15 to 8, and the old user notes get dropped in the move, 21 to 4. Meanwhile the &lt;code&gt;grapheme_mask&lt;/code&gt; vote that was announced for July 3? As far as we can tell, it &lt;strong&gt;never opened&lt;/strong&gt; — the RFC page still says draft, and the feedback stayed kind but firm. Yuya Hamada wrote: "Thank you very much for your RFC. But move to voting phase is too fast." The pipeline ahead is stacked: deprecations expects its call to vote next week, and &lt;code&gt;Duration&lt;/code&gt; finishes its cooldown just in time for the mid-August freeze.&lt;/p&gt;

&lt;p&gt;Quick hits — and there are a &lt;em&gt;lot&lt;/em&gt;, so this is a 2-slide round. July 2 was patch day: security releases for &lt;code&gt;8.2&lt;/code&gt;, &lt;code&gt;8.3&lt;/code&gt;, &lt;code&gt;8.4&lt;/code&gt;, and &lt;code&gt;8.5&lt;/code&gt;, and &lt;code&gt;8.6.0&lt;/code&gt; &lt;strong&gt;alpha 1&lt;/strong&gt; is out for testing. Eric Norris and Tim Düsterhus published the minimum-supported-versions RFC — newer autoconf, and MySQL &lt;code&gt;5.7.3&lt;/code&gt; or MariaDB &lt;code&gt;10.2.4&lt;/code&gt; for persistent connections — and an anonymous tester promptly found a real connection leak on old MySQL, declaring: "There is connection leak here!" — Eric's tracked down the cause and is weighing a fix. Nicolas Grekas redesigned &lt;strong&gt;serializable closures&lt;/strong&gt; and offered a slimmed-down fallback, nudging the list that &lt;code&gt;8.6&lt;/code&gt; won't wait. Osama Aldemeery floated a &lt;code&gt;PREG_THROW_ON_ERROR&lt;/code&gt; flag — implementation already built. And Nick Sdot posted a &lt;em&gt;tiny&lt;/em&gt; RFC: default values on &lt;code&gt;readonly&lt;/code&gt; properties, a 5-line removal — zero replies so far.&lt;/p&gt;

&lt;p&gt;Still going. Literal scalar types turned into an enums-versus-literals standoff, where Nick warned: "We should not make PHP another TypeScript." Ben Ramsey added a Foundation-SIGs section to &lt;strong&gt;Working Groups&lt;/strong&gt; and wants feedback before he votes it — or withdraws it. The DTLS experiment graduated to a working &lt;code&gt;1.2&lt;/code&gt; branch; Jakub Zelenka wants a draft PR. Pierre Joye synced bundled GD with libgd &lt;code&gt;2.4&lt;/code&gt; and is untangling Windows dependencies. Pratik Bhujel's terminal helpers got Derick's blessing — ship it via PIE, since PECL takes no new packages. And Pratik also asked whether fixing &lt;code&gt;sscanf&lt;/code&gt;'s &lt;code&gt;%c&lt;/code&gt; whitespace bug — in place since PHP &lt;code&gt;4.3.2&lt;/code&gt; — breaks anyone on master.&lt;/p&gt;

&lt;p&gt;So that's the week: a deprecations list that fought about WordPress and then about evidence, with the call to vote days away; a Duration RFC wrapped up and waiting out its cooldown; 2 rival answers to function autoloading colliding in real time; typed closures winning the room while the lexer holds the door; and the one ballot that closed, passing 26 to 1. Links to every thread are below. We're Artisan Build. See you next week.&lt;/p&gt;

</description>
      <category>news</category>
      <category>php</category>
      <category>laravel</category>
      <category>webdev</category>
    </item>
    <item>
      <title>This Week In PHP Internals | July 1, 2026</title>
      <dc:creator>Len Woodward</dc:creator>
      <pubDate>Wed, 01 Jul 2026 19:14:23 +0000</pubDate>
      <link>https://dev.to/projektgopher/this-week-in-php-internals-july-1-2026-513b</link>
      <guid>https://dev.to/projektgopher/this-week-in-php-internals-july-1-2026-513b</guid>
      <description>&lt;p&gt;Hello world, it's Canada Day 2026, and here's what happened This Week in PHP Internals.&lt;/p&gt;

&lt;p&gt;This week's episode is supported by &lt;strong&gt;OurCVEs&lt;/strong&gt;. Hundreds of CVEs ship every week, and almost none of them are about &lt;em&gt;you&lt;/em&gt; — until one is. OurCVEs inventories your entire infrastructure and only surfaces the security risks that &lt;strong&gt;actually apply&lt;/strong&gt; to your team. Free for open source at &lt;code&gt;ourcves.com&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;This week's &lt;strong&gt;top story&lt;/strong&gt; is still Gina P. Banyard's &lt;strong&gt;Deprecations for PHP &lt;code&gt;8.6&lt;/code&gt;&lt;/strong&gt; — the once-a-year housekeeping RFC that gathers a stack of unrelated removals under one roof, where each one stands or falls on its own separate vote. With &lt;code&gt;8.6&lt;/code&gt;'s first alpha getting built this very week, the clock is &lt;em&gt;loud&lt;/em&gt;. But the fight this week wasn't about any single removal — it was about &lt;strong&gt;evidence&lt;/strong&gt;: does every deprecation owe voters an impact analysis? Tim Düsterhus argued no, at least not as an unconditional rule — a deprecation has years of runway, and a survey of existing code can't measure the &lt;em&gt;upside&lt;/em&gt; of a cleanup.&lt;/p&gt;

&lt;p&gt;Juliette Reinders Folmer had offered to &lt;em&gt;build&lt;/em&gt; those impact analyses, and her exchange with Tim turned personal — an accusation of gaslighting, which Tim rejected. But she was far from alone on the substance. Rowan Tommins came to her defense, and he didn't warm up first. Rowan wrote: "I hate this argument." His point: deprecating something is really a proposal to &lt;em&gt;remove&lt;/em&gt; it later, so the impact of that removal is exactly what voters deserve to see — and to leave it out to protect your case, he said, would be dishonest. Larry Garfield backed the same call: put the impact on the table, or read the angry blog posts come December.&lt;/p&gt;

&lt;p&gt;And this particular RFC &lt;em&gt;kept growing&lt;/em&gt; right up against the freeze. Seifeddine Gmati proposed deprecating &lt;code&gt;list()&lt;/code&gt;, and got the room's attention: Ayesh Karunaratne clocked "7 million hits" for &lt;code&gt;list(&lt;/code&gt; on GitHub and called the break too big; Rowan noted you can't really retire &lt;code&gt;list()&lt;/code&gt; while &lt;code&gt;array()&lt;/code&gt; stays — to which Seif said, fine, then maybe deprecate &lt;code&gt;array()&lt;/code&gt; too. Nick moved to reserve &lt;code&gt;namespace&lt;/code&gt; as a constant name. Ilia Alshanetsky floated finally sunsetting &lt;code&gt;open_basedir&lt;/code&gt; — Derick Rethans said "Yes, but for PHP &lt;code&gt;9&lt;/code&gt;," while Jakub Zelenka was firmly &lt;strong&gt;against&lt;/strong&gt; it. Add a careful fight over how narrowly to kill the &lt;code&gt;dechunk&lt;/code&gt; filter, plus Tim's pitch to retire &lt;code&gt;gettype()&lt;/code&gt; for &lt;code&gt;get_debug_type()&lt;/code&gt;, and that's a lot of small knives being sharpened at once.&lt;/p&gt;

&lt;p&gt;Carrying over: Tim and Derick's &lt;code&gt;Time\Duration&lt;/code&gt; class — the immutable stopwatch value that's meant to be the &lt;em&gt;first brick&lt;/em&gt; of a modern date-and-time API. One line of context, then this week's moves: they're dropping the word "period" from the method names &lt;em&gt;(Derick pointed out ISO itself walked away from it)&lt;/em&gt;; they're lifting the ban on negative durations after Paweł Kraśnicki showed up with a real use case; and the whole thing may &lt;strong&gt;slim down&lt;/strong&gt; for &lt;code&gt;8.6&lt;/code&gt; — ship addition, subtraction and multiplication now, and let dividing one duration by another wait. Ignace Nyamagana Butera and Nick are already bikeshedding whether that division should hand you back a tuple or a tidy little value object.&lt;/p&gt;

&lt;p&gt;The single busiest thread of the week was brand new: Rob Landers formally opened &lt;strong&gt;Primary Constructors&lt;/strong&gt; — the whole constructor hoisted up onto the class line itself. His numbers are the pitch: something like 30 to 40 percent of all constructors are completely empty, and by his count 71 percent of Laravel and 61 percent of Symfony classes could use this. The catch is deliberate — a class with a primary constructor &lt;em&gt;can't&lt;/em&gt; also declare a regular &lt;code&gt;__construct&lt;/code&gt;, and it can't carry a body.&lt;/p&gt;

&lt;p&gt;That no-body rule is the whole fight. Nick pushed for a body — mostly so &lt;code&gt;readonly&lt;/code&gt; classes have a way through — and warned this could ship as &lt;em&gt;yet another&lt;/em&gt; half-a-feature. But Rob held the line. He wrote: "If you need a body, use a constructor -- that's what they're for." Rowan and Tim are with Rob — Tim called the limitation "a feature," and put it simply: "[To] reduce typing alone is not a sufficiently strong argument in favor of a new feature." Seifeddine went further: "Personally, I really dislike this feature." His read — primary constructors don't &lt;em&gt;remove&lt;/em&gt; repetition, they just relocate it. Larry, meanwhile, wants a Kotlin-style &lt;code&gt;init&lt;/code&gt; block bolted on. Plenty's still unresolved — visibility, attributes, anonymous classes — so we'll be keeping an eye on this one.&lt;/p&gt;

&lt;p&gt;Newcomer Michal Kral floated a spicy pre-RFC: &lt;strong&gt;methods on scalars&lt;/strong&gt;. Write &lt;code&gt;(3)-&amp;gt;pow(2)&lt;/code&gt;, or &lt;code&gt;" hello "-&amp;gt;trim()-&amp;gt;upper()&lt;/code&gt;, with the call rewritten at compile time into a hidden helper — but &lt;em&gt;only&lt;/em&gt; when the compiler can already prove the value is a scalar. He was upfront that he built it with an AI assistant. The reception was cool: Seifeddine's core objection is that PHP compiles one file at a time, so "the compiler already knows it's a scalar" covers almost no real code — the same line would work or fail depending on what's autoloaded. His fix, nicely put: "Solve the naming problem with naming, not by blinding the tooling." And Rob warned the whole thing leans on casts, which in PHP are &lt;em&gt;dangerous&lt;/em&gt; — &lt;code&gt;(int)&lt;/code&gt; of the string &lt;code&gt;"123password"&lt;/code&gt; is just &lt;code&gt;123&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;Alex Pătrănescu opened a pre-RFC for &lt;strong&gt;runtime modules&lt;/strong&gt; — a way to give each package its own private symbol table so two versions of the same library can finally coexist in one request. Rowan Tommins spent the week reframing it as &lt;em&gt;containers&lt;/em&gt; — a boundary you run other people's code inside, Docker-style — and kept circling the genuinely hard part: what happens when an object crosses the wall between two containers? A second contributor, Alexander Egorov, pitched version "tags" instead; Rowan's worry is that tags leak the container's insides right back out. No code yet — but a problem the whole ecosystem feels.&lt;/p&gt;

&lt;p&gt;The rawest thread of the week came from a &lt;em&gt;user&lt;/em&gt;, not an internals regular. Michael Morris wrote what he openly called a "Disheartening Rant" after Edmond Dantes said his own &lt;strong&gt;TrueAsync&lt;/strong&gt; RFC has, in his words, a 90 percent chance of &lt;em&gt;not&lt;/em&gt; being accepted. Morris didn't hold back: "If you want PHP to be the next COBOL, this is how you go about it." His killer example is WebSockets — the thing PHP still can't really do on its own. Ilia Alshanetsky pushed back gently &lt;em&gt;(he's actually written COBOL, and reports it isn't dead)&lt;/em&gt;: async matters, but its reach in a request-based language is narrower than it looks.&lt;/p&gt;

&lt;p&gt;Larry Garfield drew the line that matters — the same one that just sank generics. Larry wrote: "Don't confuse 'this is not the async we're looking for, done in a painful process' with 'we don't want async at all, ever.' The first is what happened. The second is simply untrue." His critique isn't of async — it's of &lt;em&gt;how&lt;/em&gt; TrueAsync arrived: enormous, one author, hundreds of far-reaching decisions, feedback taken selectively. His fix is a real working group to design it together. &lt;em&gt;Nobody's against the destination — they're against the map.&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;To the ballots — and this was a brutal fortnight for the marquee names. Seifeddine's Bound-Erased &lt;strong&gt;Generics&lt;/strong&gt; closed and was &lt;em&gt;declined&lt;/em&gt;: 7 in favour, 19 against, 10 abstaining — nowhere near the two-thirds. And Nicolas Grekas's &lt;code&gt;__exists()&lt;/code&gt; magic method went down with it, 2 to 13. &lt;em&gt;The two features that would've made the headlines both missed.&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;But look what &lt;em&gt;did&lt;/em&gt; pass — the quiet, careful stuff, every one without a single No. Tim's deprecation of returning values from &lt;code&gt;__construct&lt;/code&gt; and &lt;code&gt;__destruct&lt;/code&gt;: accepted &lt;strong&gt;unanimously&lt;/strong&gt;, 39 to nothing. Sjoerd Langkemper's cap on &lt;code&gt;php://filter&lt;/code&gt; chains — that local-file-inclusion-to-RCE fix — accepted 30 to nothing, 2 abstaining. And Weilin Du's &lt;code&gt;Locale&lt;/code&gt; display-keyword additions: in, 18 to nothing, 2 abstaining. And one's still live on the board — Jordi Kroon's move to lift third-party extension docs out of the manual is out in front at &lt;strong&gt;25 to 1&lt;/strong&gt;, one abstaining, with the vote closing July 3; on the side questions the room is leaning toward a &lt;code&gt;php.net&lt;/code&gt; subpath over a separate subdomain, 14 to 8, and toward &lt;em&gt;dropping&lt;/em&gt; the old user notes rather than migrating them, 20 to 4. The pattern's getting hard to miss: the bold swings keep getting sent back, while the tidy, well-scoped changes keep sailing home.&lt;/p&gt;

&lt;p&gt;Quick hits. That newcomer arc — Sepehr Mahmoudi's &lt;code&gt;grapheme_mask&lt;/code&gt; — got RFC karma and a warm discussion, then tried to call a vote for July 3 and was told, kindly, it's not ready: no discussion link, freeze period not met, window too short — &lt;em&gt;the process catching a first-timer before the fall.&lt;/em&gt; Khaled Alam's write-to-constants RFC grew to cover class constants, so its vote slipped. Gianfrancesco Aurecchia's &lt;strong&gt;DTLS&lt;/strong&gt; idea converged fast — Jakub steered it from a new class to a simple &lt;code&gt;dtls://&lt;/code&gt; stream, maybe no RFC needed at all. Gina volunteered to review the long-stranded &lt;code&gt;snmp&lt;/code&gt; extension work. Seifeddine's Literal Scalar Types reached version 0.3. Jorg Sowa's case-sensitive-PHP revival was withdrawn. And PHP &lt;code&gt;8.6.0&lt;/code&gt; alpha 1 got built — which is &lt;em&gt;why&lt;/em&gt; everyone's sprinting.&lt;/p&gt;

&lt;p&gt;So that's the week: a deprecations RFC that turned into a fight about honesty, a stopwatch class quietly going on a diet, a brand-new primary-constructors debate, a heartfelt plea for async — and the two flagship votes falling while the small ones walked right in. Links to every thread are below. We're Artisan Build. See you next week.&lt;/p&gt;

</description>
      <category>news</category>
      <category>laravel</category>
      <category>php</category>
      <category>webdev</category>
    </item>
    <item>
      <title>This Week In PHP Internals | June 24, 2026</title>
      <dc:creator>Len Woodward</dc:creator>
      <pubDate>Thu, 25 Jun 2026 03:41:37 +0000</pubDate>
      <link>https://dev.to/projektgopher/this-week-in-php-internals-june-24-2026-kmm</link>
      <guid>https://dev.to/projektgopher/this-week-in-php-internals-june-24-2026-kmm</guid>
      <description>&lt;p&gt;Hello world, it's Wednesday, June 24, 2026, and here's what happened This Week in PHP Internals.&lt;/p&gt;

&lt;p&gt;This week's episode is supported by &lt;strong&gt;Ballast&lt;/strong&gt; — our new gauge for whether the software you ship actually &lt;em&gt;lasts&lt;/em&gt;. Velocity tells you how fast you ship; Ballast tells you whether it &lt;em&gt;stayed&lt;/em&gt; shipped — one durability score, read straight from your git history. &lt;em&gt;No survey, no black box.&lt;/em&gt; Early access opens at &lt;code&gt;artisan.build/ballast&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;Right — Gina P. Banyard opened the annual &lt;strong&gt;Deprecations for PHP &lt;code&gt;8.6&lt;/code&gt;&lt;/strong&gt; RFC. It's the yearly omnibus: a year's worth of small removals, compiled by a dozen hands, each one voted on its own, and it has to be frozen by July 13. This year the sharpest exchange wasn't about any one removal — it was about &lt;em&gt;evidence&lt;/em&gt;. Juliette Reinders Folmer pressed the point that the proposals ship without an impact analysis: "[N]one of the proposals contain a proper impact analysis," she wrote, calling it irresponsible to ask voters to decide partly blind — and she offered to &lt;strong&gt;build&lt;/strong&gt; one, &lt;code&gt;PHP_CodeSniffer&lt;/code&gt; plus &lt;code&gt;PHPCompatibility&lt;/code&gt;, covering most of the list.&lt;/p&gt;

&lt;p&gt;Tim Düsterhus pushed back — said the claim wasn't accurate, and reminded the list that deprecations aren't a breaking change. Juliette felt that talked past her, and answered plainly: "Tim, please don't try to gaslight me." It's worth sitting with, &lt;em&gt;not&lt;/em&gt; laughing past: underneath the heat is a fair ask — give voters the data to decide. And by midweek it wasn't a two-person spat — Rowan Tommins backed the substance. A deprecation, he argued, is really a proposal to &lt;em&gt;remove&lt;/em&gt; something later, so the impact of that removal is fair to weigh; he put it bluntly: "To knowingly omit information that might weaken your case would be dishonest."&lt;/p&gt;

&lt;p&gt;So what's actually proposed for removal? A real grab-bag, each with its own argument. The &lt;code&gt;_()&lt;/code&gt; shorthand for &lt;code&gt;gettext()&lt;/code&gt; — and Rowan Tommins flagged that one as genuinely costly, since &lt;code&gt;_()&lt;/code&gt; is the canonical gettext spelling and big codebases lean on it thousands of times. Reserving the keywords &lt;code&gt;let&lt;/code&gt;, &lt;code&gt;in&lt;/code&gt;, &lt;code&gt;out&lt;/code&gt;, and &lt;code&gt;inout&lt;/code&gt;. The &lt;code&gt;CURLOPT_PROGRESSFUNCTION&lt;/code&gt; constant — where Ayesh Karunaratne argued &lt;em&gt;don't&lt;/em&gt; deprecate it at all, just quietly remap it onto &lt;code&gt;CURLOPT_XFERINFOFUNCTION&lt;/code&gt; and spare a few hundred maintainers the churn. Plus &lt;code&gt;spl_object_hash()&lt;/code&gt; and &lt;code&gt;metaphone()&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;One fresh proposal rode in on that same thread. Muhammed Arshid KV wants to deprecate &lt;code&gt;SplFileObject&lt;/code&gt;'s CSV methods — &lt;code&gt;fgetcsv&lt;/code&gt;, &lt;code&gt;fputcsv&lt;/code&gt; and the rest — in favour of a dedicated &lt;code&gt;csv&lt;/code&gt; extension. But Ignace Nyamagana Butera, who &lt;em&gt;maintains&lt;/em&gt; the &lt;code&gt;league/csv&lt;/code&gt; library, hit the brakes: "deprecating the current API without providing at least the start of a replacement API seems premature [...] Anything else would be counterproductive at the moment." Gina's standing offer to anyone with an idea: send me the text and I'll fold it in — &lt;em&gt;but I'm not writing it for you.&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;The single busiest thread of the week, though, was brand new. Tim Düsterhus and Derick Rethans proposed a &lt;code&gt;Time\Duration&lt;/code&gt; class — a first-class, immutable stopwatch value, deliberately small, aimed at &lt;code&gt;8.6&lt;/code&gt; so it can smooth the new Polling API's timeouts before the feature freeze. And it's the &lt;em&gt;opening move&lt;/em&gt; of a modern date-and-time API. Fifty-some replies followed, almost all the productive kind of argument: should a negative duration carry a sign flag or just be signed seconds? What on earth do you call dividing one duration by another? Marc Bennewitz pushed hard on the representation; Paweł Kraśnicki showed up from the &lt;code&gt;brick/date-time&lt;/code&gt; world and got a warm "welcome and thank you for contributing."&lt;/p&gt;

&lt;p&gt;When the design drifted toward a static &lt;code&gt;Duration::sum()&lt;/code&gt;, Larry Garfield drew a firm line: "I am 100% against a static method for adding durations. That's entirely pointless." He wants &lt;code&gt;$dur1-&amp;gt;add($dur2)&lt;/code&gt; — &lt;em&gt;like a civilized person.&lt;/em&gt; By Tuesday Tim had already renamed the ISO parser and added an &lt;code&gt;-&amp;gt;absolute()&lt;/code&gt; method, so this one is genuinely moving.&lt;/p&gt;

&lt;p&gt;Rob Landers opened a pre-RFC for &lt;strong&gt;Primary Constructors&lt;/strong&gt;, lifted out of his old Records proposal. Picture the whole constructor promoted up onto the class line itself. The catch in Rob's version: a class with one &lt;em&gt;can't&lt;/em&gt; also declare a &lt;code&gt;__construct&lt;/code&gt;, so real init logic has to run through property hooks — and Nick Sdot caught the snag immediately, that hooks-only means the class can't be &lt;code&gt;readonly&lt;/code&gt;. Larry's in, keep-it-simple, with a side of Kotlin. Rowan Tommins pushed back: "I don't think we should add extra syntax to the language just to change people's habits."&lt;/p&gt;

&lt;p&gt;Function autoloading came back for a &lt;em&gt;fifth&lt;/em&gt; try — Paul Jones's mark 5 of a feature internals keeps almost-shipping and never quite does. It drew the exact objection that's sunk every prior run: lean on it, forget to fully-qualify a name, and your code works &lt;em&gt;by accident&lt;/em&gt; because something else loaded that function first — then breaks silently after a refactor. Tim Düsterhus put it flatly: "Agreed on this being a non-starter for the proposal for me." Paul's answer is a &lt;code&gt;declare(strict_namespace=1)&lt;/code&gt; switch to kill the global fallback, plus a patient reply to Bob Weinand on why the engine simply can't retry name resolution cheaply.&lt;/p&gt;

&lt;p&gt;To the ballots. The headline features still can't find a two-thirds. Seifeddine Gmati's Bound-Erased &lt;strong&gt;Generics&lt;/strong&gt; is, as of this recording, sitting at 7 in favour, 19 against, 10 abstaining — and that's the &lt;em&gt;primary&lt;/em&gt;; on the syntax sub-vote the C#-style &lt;code&gt;in&lt;/code&gt;/&lt;code&gt;out&lt;/code&gt; spelling is killing it, 24 to 2. Nicolas Grekas's &lt;code&gt;__exists()&lt;/code&gt; magic method is underwater too, 2 to 12 with 7 abstentions. And Daniel Scherzer read the room on &lt;code&gt;ReflectionAttribute::getCurrent()&lt;/code&gt; — stuck at 4-7-8 — and simply &lt;strong&gt;pulled&lt;/strong&gt; the vote to rework it.&lt;/p&gt;

&lt;p&gt;The focused changes, meanwhile, are clearing without a single No. Tim Düsterhus's deprecation of returning values from constructors and destructors: 37 to nothing as of recording. Sjoerd Langkemper's cap on &lt;code&gt;php://filter&lt;/code&gt; chains — last week's local-file-inclusion-to-RCE fix — running 30 to nothing, 2 abstaining. Weilin Du's &lt;code&gt;Locale&lt;/code&gt; display-keyword additions are &lt;strong&gt;in&lt;/strong&gt; — the vote closed and the RFC's accepted, 18 to nothing. And Jordi Kroon's plan to lift third-party extension docs out of the manual is cruising at 21 to 1 — though the room is split on &lt;em&gt;where&lt;/em&gt; they should live.&lt;/p&gt;

&lt;p&gt;Tough week to be a &lt;em&gt;revival&lt;/em&gt;. Jorg Sowa brought back case-sensitive PHP, took a full week of fire — Rob Landers didn't hedge: "I honestly can't think of anything good that this RFC would bring" — and on Tuesday retired it himself, writing: "I'm sorry, but I'm going to stop work on this RFC. I see very little chance it passing." James Titcumb formally walked away from the deprecate-PEAR RFC, realising it isn't really the project's call to make, and explained: "[D]eprecating PEAR is not really within the remit of the wider PHP community [...] it's like making an RFC to deprecate Packagist." Quieter movers: Literal Scalar Types reached &lt;code&gt;v0.2&lt;/code&gt; with strict matching by default, and the &lt;code&gt;.phpc&lt;/code&gt; pure-code idea &lt;em&gt;mutated&lt;/em&gt; into an alternate opening tag, &lt;code&gt;&amp;lt;?psf&lt;/code&gt;, that could even carry a &lt;code&gt;new_scope&lt;/code&gt; directive.&lt;/p&gt;

&lt;p&gt;On the governance bench: Khaled Alam's "write to objects held in constants" RFC cleared its cooldown and is &lt;strong&gt;headed to a vote&lt;/strong&gt; June 29. And Ben Ramsey reshaped the Working Groups proposal — moving the real policy text out into a pull request so the RFC itself is just charter-and-link — still trying to give the project a little structure &lt;em&gt;without&lt;/em&gt; crowning a BDFL.&lt;/p&gt;

&lt;p&gt;One human note to end on. A few weeks back a newcomer, Sepehr Mahmoudi, floated a &lt;code&gt;get_favicon()&lt;/code&gt; function and got the classic "what problem does this actually solve" welcome. This week he &lt;em&gt;withdrew&lt;/em&gt; it himself — better suited to userland, he decided — pivoted to a &lt;code&gt;str_mask()&lt;/code&gt; helper, heard Rowan explain that real masking needs graphemes and ICU rather than raw bytes, and pivoted &lt;em&gt;again&lt;/em&gt; to &lt;code&gt;grapheme_mask()&lt;/code&gt; for the &lt;code&gt;intl&lt;/code&gt; extension, working C prototype in hand. And as of &lt;em&gt;this morning&lt;/em&gt; he's got the keys to write it up — Ilija Tovilo granted his RFC karma and signed off with a simple "Good luck!" That's the list at its best: someone turning up, &lt;em&gt;listening&lt;/em&gt;, and getting better in the open.&lt;/p&gt;

&lt;p&gt;Quick hits. Sjoerd Langkemper is &lt;em&gt;everywhere&lt;/em&gt; this week — beyond the filter-chain vote, he wants &lt;code&gt;base_convert&lt;/code&gt; to stop silently shredding entropy when you build random tokens with it, and he's adding a &lt;code&gt;ValueError&lt;/code&gt; for invalid characters to &lt;code&gt;hexdec&lt;/code&gt;, &lt;code&gt;bindec&lt;/code&gt; and &lt;code&gt;octdec&lt;/code&gt;. Osama Aldemeery floated deprecating &lt;code&gt;return&lt;/code&gt; inside a &lt;code&gt;finally&lt;/code&gt; block — the one silent abrupt-exit PHP still allows — backed by an impact analysis showing it hits just 12 sites across 9 packages, 3 of them &lt;em&gt;actual latent bugs&lt;/em&gt;; it's folding into the omnibus. Pratik Bhujel's terminal extension reached &lt;code&gt;v0.5.0&lt;/code&gt;. Gianfrancesco Aurecchia floated an &lt;code&gt;Openssl\Dtls&lt;/code&gt; class to bring DTLS — the &lt;em&gt;UDP&lt;/em&gt; side of TLS, the piece WebRTC needs — into the &lt;code&gt;openssl&lt;/code&gt; extension, proof-of-concept already green. And &lt;code&gt;8.4.23&lt;/code&gt; and &lt;code&gt;8.5.8&lt;/code&gt; both cut release candidates.&lt;/p&gt;

&lt;p&gt;That's the week: a deprecations RFC that became an argument about evidence and respect, a stopwatch class that swallowed the mailing list, two revivals laid to rest, and the headline votes still stalled while the small ones glide through. Links to every thread are below. We're Artisan Build. See you next week.&lt;/p&gt;

</description>
      <category>php</category>
      <category>laravel</category>
      <category>webdev</category>
      <category>news</category>
    </item>
  </channel>
</rss>
