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

On 18/08/2026 16.54, Larry Garfield wrote:

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 ithttps://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.) It was a kind of lazy value (the lazy value being in essense a parameters array) I was after - if by lazy value you mean a value you would only change in one place and then it would affect all places where ...COOKIE_PARAMS are used (only 6 places in my current codebase but that's room even for the parameters not to be in sync) /Henrik --Larry Garfield -- Med venlig hilsen Henrik Skov /HSK Consulting/ Blegdamsvej 128B, 4 DK-2100 Copenhagen O Tel.: +45 27 62 83 01 Email: henry.wood.dk@gmail.com