On Thu, Aug 12, 2021 at 10:42 AM Matthew Weier O'Phinney < mweierophin...@gmail.com> wrote:
> My main question is why the Util libraries would move to the PER process. > > Currently, these have been developed to provide features complementary to > a given standard: > > - cache-util and simplecache-util provides boilerplate that will be used > in most implementations, as well as default "in memory" implementations. > - http-util provides constants used for request methods and response > status codes > > In each case, I'd argue they're less "evolving standards" as they are > libraries tracking common usage or tracking non-FIG standards to provide > commonly used artifacts. In other words, they are _libraries_, not > _recommendations_. > I understand the point you are trying to make here, but I also worry that packages like `http-util` have become rather stagnant and are (oddly) difficult to work with. For instance `StatusCodeInterface::STATUS_OK` is incredibly verbose. Something like `HttpStatus::OK` would be far more elegant to work with. And when Enums are available, this package would really benefit from adopting them. My point here is that even if the util packages are "libraries" they don't appear to update and evolve like I would expect a library to. -- Woody Gilk https://www.shadowhand.com > > Otherwise, the rest of this looks fantastic! Thanks for putting this > together! > > On Tue, Aug 10, 2021 at 4:49 PM Larry Garfield <la...@garfieldtech.com> > wrote: > >> We've been talking about "living specs" for a long time. Let's finally >> define a process for that: >> >> https://github.com/php-fig/fig-standards/pull/1235 >> >> I won't resummarize it here, as the issue already does so. >> >> My expectation is that out of the gate, we'd see something like this: >> >> * PER-CodingStandards (uses PSR-12 as a basis, updating it for each new >> PHP release.) >> * PER-Cache Utils (maintains the cache-util and simplecache-util >> libraries.) >> * PER-HTTP (maintains the various PSR-7/15/17/18 util libraries.) >> * PER-DocBlocks (would replace PSR-19, the tag library, but NOT PSR-5, >> the parsing rules, which still need to get finished.) >> >> And should we decide that a "type library" (enums, etc.) is a reasonable >> thing for us to do, it would get its own PER as well. >> >> Discuss. >> >> -- >> Larry Garfield >> la...@garfieldtech.com >> >> -- >> 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 view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/0f07cf13-80e3-436d-b950-9cb7d926741b%40www.fastmail.com >> . >> > > > -- > Matthew Weier O'Phinney > mweierophin...@gmail.com > https://mwop.net/ > he/him > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/CAJp_myWyGG6Ypve1aaffwTwfwxrfn4do0c%3DJ2G4hZfY-Kr7wJA%40mail.gmail.com > <https://groups.google.com/d/msgid/php-fig/CAJp_myWyGG6Ypve1aaffwTwfwxrfn4do0c%3DJ2G4hZfY-Kr7wJA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAGOJM6Jfp7HrAg%2BJ_X%3DjuK81Cx6RnTOTxcQGbkTf5VLaReH1Lw%40mail.gmail.com.
