> Am 03.03.2021 um 14:01 schrieb Andreas Heigl <andr...@heigl.org>:
>
> I'd rather see those classes as ValueObjects that should not have to
> take care about their external representation. And a custom Formatter
> that handles all the weird edge cases as a separate entity would be a
> much easier to maintain approach. And such a Formatter can easily be
> build in userland (I think I wrote one myself at one point) and so the
> maintenance-burden would also not be added to internals.
>
> That would also apply to the DateTimeInterval::format() method but that
> would mean a massive BC break so it is most likely out of the question.
> Nevertheless I would prefer an external library to handle all those
> formatting issues and treat the DateTime lib as internal ValueObjects
I’d like to respectfully disagree. If we were to go down the ValueObject route,
DateTime/DateInterval should not be able to create new instances from formatted
strings in the first place. PHP Date classes have always been intertwined with
their output formatting however, so this is how the ecosystem uses them. In
that sense, I’d expect DateInterval to be able to return the format it was
instantiated with, but it isn't.
The PHP API may have its warts, but I prefer my warts consistent.
Regards
Moritz
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
