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

Reply via email to