On 27/06/2022 13:03, Guilliam Xavier wrote:
Reminded me of e.g.
https://stackoverflow.com/questions/6422380/does-any-programming-language-support-defining-constraints-on-primitive-data-types
(mainly integer ranges, but the concept of "domains" looks similar)
Yes, I'm vaguely familiar with the
On Wed, Jun 22, 2022, at 12:26 PM, Larry Garfield wrote:
> So I am firmly against making it easier to (mis)use enums in a
> situation where constants are already the superior solution by every
> metric. The only argument I see is making case 1, transitioning from a
> string to an enum for a ge
>> Symfony YAML has a `!php/const X` feature, which also works when X is
>> an Enum::CASE; how about a `!php/enum_value` feature?
>
> I submitted something similar today at
> https://github.com/symfony/symfony/pull/46771
And I see that it has been merged ;)
>> Otherwise, I also like Rowan's sugg
Hi Nicolas,
On Fri, 24 Jun 2022 at 17:38, Nicolas Grekas
wrote:
>
> I'm now considering withdrawing the RFC because I don't see a way forward
> that could be consensual enough.
Just in general, I think changes to the type system are always going
to take longer than a few weeks to discuss. There
Hi Guilliam,
> > There are also cases where using "->value" is just not possible. I
> mention
> > attributes in the RFC,
>
> which also mentions
> https://wiki.php.net/rfc/fetch_property_in_const_expressions (but with
> "For people that use non-strict mode, this extra “->value” is
> boilerplate t
> domain SymfonyPermission: string;
> domain AcmePermission: string { 'admin' | 'user' | 'bot' };
> [...]
> Domains can also be considered sets, which you could compare directly,
> and maybe even calculate intersections, unions, etc:
>
> The actual values would be ordinary strings, and type constra
Hi Nicolas, thanks for the RFC,
> There are also cases where using "->value" is just not possible. I mention
> attributes in the RFC,
which also mentions
https://wiki.php.net/rfc/fetch_property_in_const_expressions (but with
"For people that use non-strict mode, this extra “->value” is
boilerplat
On Wed, Jun 22, 2022, at 4:43 PM, Rowan Tommins wrote:
> On 22/06/2022 18:26, Larry Garfield wrote:
>> The argument presented is that it's easier to type `AppRoles::Admin` than
>> `"admin"`, because the former provides you with an error if you typo
>> something. That's a valid argument, but... n
On Wed, Jun 22, 2022, at 2:31 PM, Alexandru Pătrănescu wrote:
> On Wed, Jun 22, 2022 at 8:27 PM Larry Garfield
> wrote:
>
>>
>> So I am firmly against making it easier to (mis)use enums in a situation
>> where constants are already the superior solution by every metric. The
>> only argument I see
On Wed, Jun 22, 2022 at 6:01 PM Nicolas Grekas
wrote:
> Hi Benjamin and Derick,
>
> I'm replying to both of you because I see some things in common in your
> comments.
>
> >
>> https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums
>
>
> I would prefer if this was an explicit
On 22/06/2022 18:26, Larry Garfield wrote:
The argument presented is that it's easier to type `AppRoles::Admin` than
`"admin"`, because the former provides you with an error if you typo something.
That's a valid argument, but... not for using enums. It's an argument for using
constants.
I
On Wed, Jun 22, 2022 at 8:27 PM Larry Garfield
wrote:
>
> So I am firmly against making it easier to (mis)use enums in a situation
> where constants are already the superior solution by every metric. The
> only argument I see is making case 1, transitioning from a string to an
> enum for a genui
Hi
On 6/22/22 19:26, Larry Garfield wrote:
In case 1, I'd argue that the function should be switching to an Enum long term *and dropping the
string*. For that, a union type is the optimal solution. Does that have BC implications for
sub-classes? Well, yes, but so does any type improvement.
On Wed, Jun 22, 2022, at 8:05 AM, Derick Rethans wrote:
> On 21 June 2022 23:47:15 BST, Nicolas Grekas
> wrote:
>>Hi everyone!
>>
>>I'd like to open a discussion on this RFC, to auto-implement Stringable for
>>string-backed enums:
>>https://wiki.php.net/rfc/auto-implement_stringable_for_string_ba
On Tue, 21 Jun 2022 at 23:47, Nicolas Grekas
wrote:
> Hi everyone!
>
> I'd like to open a discussion on this RFC, to auto-implement Stringable for
> string-backed enums:
> https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums
>
Hi Nicolas,
Like others, I'm lukewarm on this
Hi Benjamin and Derick,
I'm replying to both of you because I see some things in common in your
comments.
>https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums
I would prefer if this was an explicit opt-in to have a __toString on a
> backed enum. Maybe a special trait for
On 21 June 2022 23:47:15 BST, Nicolas Grekas
wrote:
>Hi everyone!
>
>I'd like to open a discussion on this RFC, to auto-implement Stringable for
>string-backed enums:
>https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums
>
>I'm looking forward to your feedback,
I am not in
On Wed, Jun 22, 2022 at 12:47 AM Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:
> Hi everyone!
>
> I'd like to open a discussion on this RFC, to auto-implement Stringable for
> string-backed enums:
> https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums
>
> I'm looking
Hi everyone!
I'd like to open a discussion on this RFC, to auto-implement Stringable for
string-backed enums:
https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums
I'm looking forward to your feedback,
Cheers,
Nicolas
19 matches
Mail list logo
