Hi everyone, Apart from cardinal directions, some common enums could be - Log levels (PSR-3 will need another update) - Units of measurement: distance, area, time, temperature, ..
-- Alessandro Chitolina Il giorno venerdì 28 maggio 2021 alle 01:04:06 UTC+2 Larry Garfield ha scritto: > On Thu, May 27, 2021, at 9:09 AM, Matthew Weier O'Phinney wrote: > > > When it comes to HTTP status codes and request methods, the IETF has > > left them deliberately open-ended. That said: > > > > - The specification allows for flexibility to add more within certain > > parameters, and > > - They have a process for petitioning to make new additions canonical. > > > > What the current http-message-util does is codify the ones that are > > already canonical. The primary reason to use them is not so much to > > consume and validate an HTTP message, but to _create_ one. For example, > > with HTTP clients, having the ability to select an enum for a given > > request method helps prevent potential typos. If you are choosing to > > use a non-canonical request method, you will need to deliberately steer > > clear from using the enum, which in turn should trigger a bit of extra > > review on either your part or your team's part. Similarly, for status > > codes, these are generally of interest when creating the response. The > > way we've defined the constants is to use their semantic name as the > > constant name, which in turn makes it easier to indicate _intent_ as > > you create the response. > > > > Yes, these _can_ also be used for validations, or if you want to see if > > a request method or status code matches a known canonical value, but, > > as noted, you should always be able to fall back to either range checks > > or a regexp. > > > > As such, I'd argue that having enums is a _starting point_ for message > > validation, and an important one, and a _requirement_ for users > > creating messages, with the understanding that they _can_ break out of > > the defined values as needed, again, as long as they provide values > > that fit in the standard ranges or ABNF. > > However, if you type a parameter or return value with an enum, then by > definition you cannot pass an arbitrary int instead. You would be > constrained to only allow values in that specific enum definition already. > > I suppose you could allow Status|int, but then you have to always check > which one it is and take different actions. I don't know if that's really > an improvement. > > I realize I may be arguing against myself now, but that's why I started > the discussion. :-) > > What about other common enums besides HTTP codes? Like, cardinal > directions? There's only 4 of those, worldwide, and i don't expect any new > ones to be added soon. > > --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/b3c9d37d-f301-42fb-83b8-ca76d472e472n%40googlegroups.com.
