On Mon, May 24, 2021 at 10:25 PM Michael C <m...@michaelcullum.com> wrote:
> I echo Jordi's thoughts and think doing enums once for easy, common and > uncontroversial enum sets makes sense but would steer away from anything > that could be hard to define a finite set for. We would also need to > consider a policy for changes to the set I think (is adding new element > considered a BC break, do we want to support doing so but only in major > versions [semver] etc.). > When I'm thinking about enums, I also think it's important to always be aware of having it as a finite set. Otherwise, the BC breaks of adding or removing a case will pop up often. > > Personally I'd lean towards having a separate package just for enums, but > perhaps bundling all the FIG enums into that one package. I don't think > bringing along PSR-7 is really necessary and can imagine plenty of people > and ecosystems that don't use PSR-7 using this enum set. > > One thing I would note - this is probably relatively time-sensitive, in > that we probably want to get something out before there are already 14 > competing standards for us to add a 15th. > > Many thanks, > Michael > > On Mon, 24 May 2021, 18:06 Larry Garfield, <la...@garfieldtech.com> wrote: > >> On Mon, May 24, 2021, at 10:57 AM, Matthew Weier O'Phinney wrote: >> > You're aware we have constants defined already in the >> > fig/http-message-util library, right? Couldn't we just add an enum >> > later, once 8.1 is ready? >> > >> > (I'd argue that, in general, the *-util packages are a good place for >> these.) >> >> I am unsurprised to learn it. :-) >> >> For HTTP-related enums, that may be a good place to put it. However, >> making them their own package may be helpful for those not already using >> PSR-7. (Or, maybe we do want to put it in that package to encourage people >> to use PSR-7? Interesting question.) The current PSRs (naturally) don't >> use any enums themselves, either. >> > I think "naturally" here might have other meanings as well. A http request method enum will not be complete for usage in all places because in fact a http method is just a string as I should be able to send BLABLABLA in my http client if I want to. Or receive it on my server. And because of that, they cannot be easily used as types in PSR-7, PSR-18. I think using string constants is fine here. Same thing for http response code; eventually Cloudflare will return a 524 timeout response code that is not included. Well, for this actually it can be defined as an integer between 100 and 599 but that's not practical. So only StatusCategory enum looks good from my point of view. > >> There's likely other enums that it makes sense to have a single >> definition of, but don't fit neatly into a single existing PSR/util package. >> >> -- >> Larry Garfield >> la...@garfieldtech.com >> >> Regards, Alex -- 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/CAAwdEzBQvW3SaJH8fvzjN5rsSuEB280e2iab_JEcJ-cbVoesJQ%40mail.gmail.com.
