Sent from my iPhone
> On 23 May 2024, at 03:58, Larry Garfield <la...@garfieldtech.com> wrote: > > On Wed, May 22, 2024, at 2:29 AM, Stephen Reay wrote: >>>> On 22 May 2024, at 07:58, Larry Garfield <la...@garfieldtech.com> wrote: >>> >>> given that the casing for an enum should be CamelCase (per PER-CS) >> >> Hi Larry; >> >> I find myself yet again having to ask that php policies/discussions not >> revolve around the idea that PHP-FIG is a required/expected part of PHP >> usage. >> >> Until a PHP RFC specifying "proper" casing for userland enums passes, >> can we leave the claims about what they "should be" out of discussions >> about language/stdlib functionality? > > 1. The status quo in the ecosystem is relevant to language development. FIG > is a part of that ecosystem. "Everyone in Laravel does X" or "this would > break Symfony which does Y" are also a relevant observation to make, though > in neither case is it a binding dictat, of course. By a similar token, the > language doesn't require class-per-file, but the de facto standard for > virtually every project that isn't WordPress is to use class-per-file for > autoloading. It would be highly stupid of us to ignore that fact when > discussing autoloader improvements. > > 2. The Enum RFC used PascalCase. The PHP maual uses PascalCase. We're > already recommending PascalCase as the standard for enum cases. > > Those who aren't following that recommendation are, from what I've seen, > using ALL_CAPS. Meaning using lower_case is NOT typical, and thus the issue > I mentioned (that automatically using the case name as the backing string > name may not be all that useful) is present either way. > > --Larry Garfield > Hi Larry, I didn't say the community or common uses should be ignored. I just asked you not to use the phrase "X should be Y because of <external entity>". It suggests authority where none exists. Cheers Stephen
