> On Jun 29, 2021, at 8:49 AM, Larry Garfield <la...@garfieldtech.com> wrote: > > On Tue, Jun 29, 2021, at 6:34 AM, Vincent de Lau wrote: >> Thinking about this the last couple of days, there were two topics that >> feel worth sharing: >> >> 1. Instead of specifying a specific enumeration in a PSR, a PSR could >> also describe a policy for how to maintain a specific enum package. For >> instance, the mentioned country codes for phone numbers PSR could >> specify that the implementation will be updated when the ITU E.164 >> registry changes. New enum entries will be added, old entries could be >> deprecated an removed after 2 years. The PSR could contain an initial >> implementation, especially if there are additional methods on the enum. >> >> 2. Given the mission of the FIG, should we try to limit ourselves to >> enums that have interop benefits? For instance, log levels and HTTP >> status codes seem like good candidates, but I can't readily see units >> of measurement (except potentially for time) being of direct use. > > Any Enum collection would have to operate via a "living working group" > process, which we'd have to define first. (The same holds for any new coding > standards document; the current PSR process is simply not feasible for that.)
It seems to me that figuring out a process for “living working group” is something that has come up before and is almost mandatory for doing Enums. Maybe that should be the priority right now? Woody > > I'd say overall, good targets for FIG enum collections would be: > > * Fixed lists defined already by some other standards body that we're porting > to PHP. (Eg, RFCs, W3C specs, etc.) > * Very common but logically closed lists. For instance, SortOrder::Asc vs > SortOrder::Desc. Basically every DBAL is going to have that in it somewhere, > and it's not like there's a 3rd option, so that tiny Enum likely makes sense. > > The point that HTTP codes and methods are *technically* an open list, not a > closed list, is valid, and makes those less practical. OTOH, with Union > types one could allow for int|HttpCode as a type, and then fold down to int > internally. However, I don't know if that actually provides significant > benefit over just a collection of constants. (Which I suppose we could also > produce if there was interest.) > > --Larry Garfield > > -- > 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/680199c0-1258-4f15-9eda-9bcf341d7cef%40www.fastmail.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/A892A0D8-702A-4C0E-9176-750D9D114CFD%40gmail.com.
