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