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

From: Date: Wed, 26 Aug 2026 23:27:24 +0000
Subject: Re: [Pre-RFC] Idea: named parameter lists
References: 1 2 3 4 5 6 7 8 9  Groups: php.internals 
Request: Send a blank email to internals+get-132356@lists.php.net to get a copy of this message
On Tue, Aug 18, 2026 at 5:57 PM Larry Garfield <larry@garfieldtech.com> wrote: > 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. Slightly offtopic, but I will try to answer this question. By "unworthy", most often people mean a cognitive overhead as I would call it. It's not necessarily about technical expensiveness, even though many people do think that adding an additional class will add some technical overhead. It's more about perception. And also about development complexity sometimes. I could give numerous examples, but will stick to only one. Imagine you have a function which should return not only "main" data, but also some additional data which comes for free while processing the original request. If we were forced to go the "right way", we would need to introduce a separate Dto which will hold "main" and "secondary" data. But adding a Dto for this single case may seem "unworthy", because from a cognitive point of view it is much easier to return an array of [$main, $secondary]. And later on the calling side do the unpacking [$main, $secondary] = $this->myFunction(...). And given that we have lots of tools today to describe this array on PhpDoc-level for static analysis, this solution won't be worse than a dedicated Dto in terms of proper data-structures. But still looking simpler cognitive-wise than a dedicated Dto.

« previous php.internals (#132356) next »