We had an interesting discussion on the WG Slack channel and, as far as I'm concerned, I got to share the design concerns raised by Tobias and shared by Woody.
As such, I'd like to change my vote to a -1, because I think the current draft can be made better by segregating the interfaces and avoiding the inheritance as suggested. The main argument for shipping extended interfaces for [Request|Response]FactoryInterface is easier end-user consumption, i.e. fewer collaborators to depend on. I ultimately think that, if such a purpose has to be attained, it should be done not at the expense of the simplicity of the overall design. Possible alternatives would be including a couple of facade interfaces in the standard, *in addition to simple ones*, or a full fledged composite implementation in a *-utils package. Il giorno sab 19 mag 2018 alle ore 09:01 Tobias Nyholm < tobias.nyh...@gmail.com> ha scritto: > I really like the work you've put in and I'm sorry I'm late replying here. > As you may or may not know, I'm maintaining Buzz, HTTPlug (and sometimes > Guzzle). I've also written a PSR7 implementation with factories from > HTTPlug and php-interop. (https://github.com/nyholm/psr7) > > I've just read and tested(!!) the specification we are voting on. I'm not > sure it works to be honest. Here are a few things I found: > > *Namespace* (minor): Should we really share the namespace with PSR7? Just > use 'Psr\Http\MessageFactory' > > *Interfaces extending* (critical): I've read the arguments on the meta > document. The four bullets ( > https://github.com/php-fig/fig-standards/blob/master/proposed/http-factory/http-factory-meta.md#53-why-do-some-interfaces-extend-others) > are all very true but none is an argument for the interface to extend each > other. > > The first bullet about this in the meta document says: > > The RequestFactoryInterface and ServerRequestFactoryInterface may each > need to build a UriInterface from a string URI. > > Inheritance is not the answer here. Please use a constructor to inject the > dependencies (or if you are lazy, do like me > https://github.com/Nyholm/psr7/blob/0.3.0/src/Request.php#L58). > Consider a MailFactoryInterface. The mail factory implementation may need > an EmailValidator. Should the MailFactoryInterface really extend > EmailValidatorInterface?... > > I found it very hard to write factory implementation with these > interfaces. Most of my classes have to extend each other and I have to put > the stream factory implementation in a Trait. > > *Existing libraries* (major): HTTPlug has been an "de-facto" standard for > almost 3 years now. The php-http/message-factory has been downloaded over > 4M times. We (HTTPlug) like PSR-17 and we think it is about time PHP-Fig > delivers a "real" standard for this. However, the current state of PSR-17 > will not allow HTTPlug to extend PSR-17. It will also not allow > implementing libraries (like guzzle/psr7 and nyholm/psr7) to have one > RequestFactory for both PSR-17 and HTTPlug. > > There is no mentioning about HTTPlug in the meta docs so I'm not sure it > has been discussed. This is important for the adoption of the PSR-17. > > > ----------------- > > These are 3 of my concerns. I really hope that everybody in the working > group have considered these 3 things before you voted. Or else there I > believe there is a change to change your vote until the voting period is > over or until everybody has voted. > > I will give my vote on the 29th of May. > > > > Den torsdag 17 maj 2018 kl. 16:52:17 UTC+2 skrev Glenn Eggleton: >> >> +1 >> >> On Tuesday, May 15, 2018 at 12:06:02 PM UTC-4, Matthew Weier O'Phinney >> wrote: >>> >>> Woody has delegated to me to open a vote to enter the REVIEW period for >>> PSR-17. This vote is open only to PSR-17 Working Group members; at this >>> time, that means: >>> >>> - Woody Gilk (Editor) >>> - myself (Sponsor) >>> - Stefano Torresi >>> - Matthieu Napoli >>> - Korvin Szanto >>> - Glenn Eggleton >>> - Oscar Otero >>> - Tobias Nyholm >>> >>> The by-laws do not stipulate a time-frame for how long the vote must >>> run, though 2 weeks is the standard period. As such, the vote will run >>> until 23:59:59 on 29 May 2018, or until all members have responded. Once >>> the vote is closed, I >>> will post the results, and indicate next steps for the proposal. >>> >>> PLEASE DO NOT RESPOND TO THIS POST UNLESS YOU ARE ONE OF THE MEMBERS >>> LISTED ABOVE. >>> >>> -- >>> Matthew Weier O'Phinney >>> mweiero...@gmail.com >>> https://mwop.net/ >>> >> -- > You received this message because you are subscribed to the Google Groups > "PHP Framework Interoperability Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to php-fig+unsubscr...@googlegroups.com. > To post to this group, send email to php-fig@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/779dc60c-8b87-4245-8152-fc566e27b932%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/779dc60c-8b87-4245-8152-fc566e27b932%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAFojS1v75M2d-%3DATRfawM3MG7_Xf-OJkbAey8FugiLqSRqkZZg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
