Re: [PHP-DEV] [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: [email protected]