> On Feb 11, 2020, at 10:58, Ben Ramsey <firstname.lastname@example.org> wrote:
> Regarding the array of arrays for $accept* and $forwarded, what are your thoughts on using value objects with properties, rather than arrays with keys?
It's a fair suggestion, but I am not keen to expand the number of new declarations any more than necessary.
To play with your idea a little bit, let's say we start with ...
.... then to bring in Jan Schneider's suggestion, we add ServerResponseInterface (4 classes).
Then we add the value objects themselves: ServerRequestAcceptValue and ServerRequestForwardValue. That's 6 classes.
That's maybe not so bad. But, once we start down this path, it's easy for me to imagine what comes after.
For example, since we're trying to do "the right thing," someone will suggest to typehint the properties "correctly." Instead of arrays of value objects, they probably ought to be collection objects. That gets us ServerRequestAcceptValueCollection and ServerRequestForwardValueCollection, and we're at 8 classes.
Then someone is likely to say that there ought to be interfaces for all those so their implementations can get swapped out. That's ...
.... 12 classes and interfaces. And probably not done yet, once others really sink their teeth into it.
Now, that's not a *wrong* approach -- but it does seem like overkill to me.
Or, we could avoid starting down that path and stick with arrays, which in ServerRequest are read-only and immutable and get us all the things we actually need for our daily work here.
Of those two, I prefer the minimalist approach of arrays for this RFC; the "effort-to-benefit" ratio is much better.
Paul M. Jones
Modernizing Legacy Applications in PHP
Solving the N+1 Problem in PHP