Re: [RFC] [Discussion] Stringable Enums

On Thu, Dec 4, 2025, at 2:44 PM, Bob Weinand wrote: > Good point Derick, > > On 4.12.2025 14:36:14, Derick Rethans wrote: >> On Thu, 4 Dec 2025, Tim Düsterhus wrote: >> >>> Hi >>> >>> Am 2025-12-04 09:01, schrieb Rowan Tommins [IMSoP]: >>> >>>> And is it even a good name for those methods? In the date-time >>>> package, for instance, it would be better named toEnglishName() or >>>> getFullEnglishName(), as its docblock explicitly says. In the >>>> framework code, it seems to be used for a property called >>>> $displayValue, so the obvious name for the method would be >>>> getDisplayValue(). >>> I fundamentally disagree with the proposal for reasons similar to those that >>> Rowan mentioned. More specifically, I consider implementing >>> __toString() to >>> be a mistake, unless it is for a debug representation. >> I agree, and also: >> >> We usually have a __debugInfo() method for debugging >> purposes. Instead >> of allowing __toString() to be added, I think I would >> rather see >> __debugInfo() being allowed. >> >> It must continue to be not possible to treat enums as strings. >> >> cheers, >> Derick > > > Daniel, if you want to improve the magic method situation here, I'd much > rather encourage you to add __debugInfo() than anything else. > > (Also fwiw I think __toString() should never have existed in the first > place; but that's a wholly different topic.) > > > Bob I've long argued against allowing __toString() for reasons others have already covered, so I won't bother repeating it. But off hand I don't see why __debugInfo() would cause a problem. I am not sure it's useful before ADTs happen, but I don't think it would cause any harm? --Larry Garfield