Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118054
MIME-Version: 1.0
References: <CAOWwgpmG33Ybp6KS4ePrMgMJdW5xX+M2mos2cpgoVNUy8dVMjQ@mail.gmail.com>
 <9C11261B-B9D0-4342-81EB-60276B3036E5@php.net>
In-Reply-To: <9C11261B-B9D0-4342-81EB-60276B3036E5@php.net>
Date: Wed, 22 Jun 2022 18:01:13 +0200
Message-ID: <CAOWwgpkd3OEu1VReP8gMnFdwPAQyPywQ9Ttie+grcNeXzsKS2Q@mail.gmail.com>
To: Derick Rethans <derick@php.net>, Benjamin Eberlei <kontakt@beberlei.de>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fd35f405e20b7213"
Subject: Re: [PHP-DEV] [RFC] [Under Discussion] Auto-implement Stringable for
 string backed enums
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000fd35f405e20b7213
Content-Type: text/plain; charset="UTF-8"

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 enums that has the implementation,
> so that a custom __toString cannot be implemented or a new syntax "enum Foo
> : Stringable".
>

We can make this opt-in by simply allowing user-land to implement
Stringable.
This is a different solution to the problem the RFC tries to solve and I
would also personally be fine with.
I would then *not* try to limit which implementation of it is allowed by
the engine. Instead, I would give all powers to user-land to decide on
their own what makes sense for their use case. As a general principle, I
believe that empowering user-land is always a win vs trying to "save them
from themselves", as if we knew better than them what they want to achieve,
and especially how.


> My concern is that auto implementing __toString, will lead to decreasing
> type safety of enums in weak typing mode, since they get auto-casted to
> string when passed to a function accepting strings. This effectively adds
> more type juggling cases.
>

I don't share this concern: if an API accepts a string and the engine can
provide a string, let it do so. There is nothing inherently dangerous in
doing so. But we don't need to agree on that if the proposal above makes
sense to everybody :)


> The example in the RFC about attributes accepting strings or Enums can be
> solved by union types on the side of the library developers, it doesn't
> need to be magically implemented by the engine.
>

I extensively explain in the RFC why this should not be on the side of lib
authors, but on the side of end-users. Please double check and let me know
your thoughts.


> I don't consider "use strict mode" a good argument to avoid this problem,
> because that has other downsides such as overcasting.
>

I'm 100% aligned with that.

2. It is not implemented for all enum types, only for string backed ones.
> This change would now make different classes of enums, without them being
> differently inherited classes.
>

This would also be solved by allowing user-land to implement Stringable on
*all* kind of enums. Would that make sense to you?


> 3. The main use case seems to be to prevent having to type ->value, which
> would otherwise indicate reliably whether an enum is used as string
> argument.
>

Yep, that's a "strict mode" approach and this RFC mostly applies to
non-strict mode.
There are also cases where using "->value" is just not possible. I mention
attributes in the RFC, but we also have a case in Symfony where defining
service definitions in yaml doesn't work with enums because there is no way
to express the "->value" part.

If that's the consensus, I'm fine updating the RFC to turn the vote into
whether "allowing user-land to implement Stringable on any kind of enums"
is desired or not.

Nicolas

--000000000000fd35f405e20b7213--