Agreed with Paul. I think it would also behoove the group to be careful about what is enumerated. HTTP Status codes were the first one to come up, as Larry has made a pretty neat library for those - however, I think in general HTTP status codes are already pretty portable as numbers. Turning them into Enumerations would make them less portable and, in my opinion, would go against the goal of FIG.
If enumerations were to be suggested for FIG, I would suggest things that are more likely to be represented different ways by different libraries. Items such as Months or Days of the week or basic colors. On Monday, May 24, 2021 at 7:05:39 PM UTC-4 Paul Dragoonis wrote: > On Sat, May 22, 2021 at 1:51 AM Larry Garfield <la...@garfieldtech.com> > wrote: > >> Greetings, FIGlets. (What does one call a FIG-involved person, anyway? >> FIGlet? FIGment?) >> > > We're definitely FIGlet's ;-) Spiderfig, spiderdig, codes whatever a > spiderfig codes. > > >> >> As you may be aware, PHP 8.1 is going to include support for >> Enumerations. >> >> https://wiki.php.net/rfc/enumerations >> >> I believe it would be beneficial for some common industrial enumerated >> types to have a common library, rather than everyone making their own. The >> first examples that jump out at me are HTTP status codes and methods, which >> I have implemented here: >> >> https://github.com/Crell/EnumTools >> >> There are likely others, but I haven't come up with them yet. (Obviously >> this code won't run on any released PHP version yet, but I'm pretty sure >> the syntax is right...) >> >> I am fine hosting these myself, but it occurs to me that they may be of >> more value if hosted by a more prominent organization, such as FIG. Of >> course, it's not really a spec; a PSR for these wouldn't make any sense. >> It's more akin to the Util libraries that we maintain for various PSRs, but >> without an associated PSR. >> >> How do folks feel about FIG hosting such an enum collection? We could >> make it one package or several, depending on how we decide to break it up. >> If FIG is OK hosting it I am happy to dump the enums I already build into >> whatever package FIG wants to use for them. >> > > I think we need to gracefully add Enum's into our existing packages (HTTP, > Cache ..etc) and then also see how PHP8.x enum's are being used in the wild. > > Over time we'll be able to spot the patterns and then begin reacting > accordingly. > > I think we'd be jumping the gun if we tried to go this now. Let's see how > the dust settles in the PHP community, and then we make our move. > > I think a generic enum package is fine, but to be honest having it > contextualized inside a particular package (a bounded context) is a > stronger move. > > >> >> 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+u...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/9fa79e25-5755-4f3f-9be9-3acc2ee67c6a%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/9eae2c0b-a130-4670-b490-c0d7d2483d0an%40googlegroups.com.
