Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108527 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 39439 invoked from network); 13 Feb 2020 03:54:23 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 13 Feb 2020 03:54:23 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 01A6D1804DA for ; Wed, 12 Feb 2020 18:08:40 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS29169 217.70.176.0/20 X-Spam-Virus: No X-Envelope-From: Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 12 Feb 2020 18:08:38 -0800 (PST) X-Originating-IP: 107.223.28.39 Received: from [192.168.1.85] (107-223-28-39.lightspeed.nsvltn.sbcglobal.net [107.223.28.39]) (Authenticated sender: pmjones@pmjones.io) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id EC8E220004; Thu, 13 Feb 2020 02:08:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) In-Reply-To: Date: Wed, 12 Feb 2020 20:08:33 -0600 Cc: internals@lists.php.net Content-Transfer-Encoding: quoted-printable Message-ID: References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io> To: Ben Ramsey X-Mailer: Apple Mail (2.3608.60.0.2.5) Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2) From: pmjones@pmjones.io (Paul M . Jones) Hi Ben, > On Feb 11, 2020, at 10:58, Ben Ramsey wrote: >=20 > 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 ... - ServerRequest - ServerResponse - ServerResponseSender ... 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 ...=20 - ServerRequest - ServerResponse - ServerResponseInterface - ServerResponseSender - ServerRequestAcceptValue - ServerRequestAcceptValueInterface - ServerRequestAcceptValueCollection - ServerRequestAcceptValueCollectionInterface - ServerRequestForwardValue - ServerRequestForwardValueInterface - ServerRequestForwardValueCollection - ServerRequestForwardValueCollectionInterface ... 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. --=20 Paul M. Jones pmjones@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php