Re: [Pre-RFC] Idea: named parameter lists

From: Date: Tue, 18 Aug 2026 14:54:16 +0000
Subject: Re: [Pre-RFC] Idea: named parameter lists
References: 1 2 3 4 5 6 7 8  Groups: php.internals 
Request: Send a blank email to internals+get-132262@lists.php.net to get a copy of this message
On Tue, Aug 18, 2026, at 9:07 AM, Henrik Skov wrote: >>> Yes, but I think one should consider params COOKIE_PARAMS {...} more of a type ! >> Then why not create a type for it >> https://3v4l.org/lNjSX#vgit.master > -- > Because it is not worthy of a full class. I really don't understand why people keep saying this. What makes something "unworthy" of being a class? Classes are not expensive, at least not as expensive as people seem to think. A data construct doesn't need to be as righteous as Thor to be "worthy" of a class. Plus, in PHP, building new things on top of classes/objects (like enums) is way, way easier than new standalone constructs. > By the same logic, why do we have enums ? > A class of constants works just as fine as an enum ? It does not, because it doesn't create a bounded space. Constants are just a shorthand for "any int" or "any string." > Maybe I shouldn't have said 'type' - What I meant was language construct I think If what you're ultimately after is a "lazy value" that isn't evaluated until it is read, I could see a use for that. Binding it to "parameters" makes no sense, though. And in practice, such a feature would almost certainly end up build on top of either closures or objects anyway. (And closures themselves are just objects, in fact.) --Larry Garfield

« previous php.internals (#132262) next »