> On Jun 29, 2021, at 8:49 AM, Larry Garfield 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
>>
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.
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
> - Units of measurement: distance, area, time, temperature, ..
That'd be a tough one. Here's the unit list defined by Unicode CLDR:
https://github.com/unicode-org/cldr/blob/release-39/common/main/en.xml#L5965-L6998
--
Michele
On Saturday, June 26, 2021 at 4:19:03 PM UTC+2 alek...@gmail.com
Country codes for phone numbers as well, though this is subject to change and
may not fit nicely into a static PSR.
Sent from my iPhone
> On Jun 26, 2021, at 9:19 AM, Alessandro Chitolina wrote:
>
>
> Hi everyone,
> Apart from cardinal directions, some common enums could be
>
> - Log
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,
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
On Mon, May 24, 2021 at 3:41 PM Alexandru Pătrănescu
wrote:
> On Mon, May 24, 2021 at 10:25 PM Michael C wrote:
>
>> On Mon, 24 May 2021, 18:06 Larry Garfield,
>> wrote:
>>
> On Mon, May 24, 2021, at 10:57 AM, Matthew Weier O'Phinney wrote:
>>>
>>>
> A http request method enum will not be
On Mon, May 24, 2021 at 12:06 PM Larry Garfield
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
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
On Sat, May 22, 2021 at 1:51 AM Larry Garfield
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
On Mon, May 24, 2021 at 10:25 PM Michael C 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
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
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
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.)
On Fri, May 21, 2021 at 7:51 PM Larry Garfield
wrote:
> Greetings,
On 22/05/2021 02:51, Larry Garfield wrote:
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:
Greetings, FIGlets. (What does one call a FIG-involved person, anyway?
FIGlet? FIGment?)
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
17 matches
Mail list logo
