Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118060
Message-ID: <1cc14578-77eb-6cdc-95b3-1362d94765b8@bastelstu.be>
Date: Wed, 22 Jun 2022 19:52:46 +0200
MIME-Version: 1.0
Content-Language: en-US
To: Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
References: <CAOWwgpmG33Ybp6KS4ePrMgMJdW5xX+M2mos2cpgoVNUy8dVMjQ@mail.gmail.com>
 <9C11261B-B9D0-4342-81EB-60276B3036E5@php.net>
 <2cee17c0-7b77-4709-94b9-598a4c3d1f49@www.fastmail.com>
In-Reply-To: <2cee17c0-7b77-4709-94b9-598a4c3d1f49@www.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] [Under Discussion] Auto-implement Stringable for
 string backed enums
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

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.  This is a known problem space, with known solutions and migration strategies.  It's conceptually no different from migrating from "this takes a string" to "this takes an array of strings": Widen the type, have transitional code, retighten the type.  The time frame for that could be weeks, months, or years depending on the situation, but it's not a novel concept.

Exactly this. It might be painful for existing code, but I expect any 
newly written and any updated code to handle enums "natively" and so 
this is something that will solve itself over time.

On the other hand once the enum type safety is watered up by allowing 
implicit string conversions, there is no easy way to revert this.

Best regards
Tim Düsterhu