Bug #80047 [Csd]: DatePeriod doesn't support custom DateTimeImmutable

Edit report at https://bugs.php.net/bug.php?id=80047&edit=1 ID: 80047 Updated by: cmb@php.net Reported by: oognic at gmail dot com Summary: DatePeriod doesn't support custom DateTimeImmutable Status: Closed Type: Bug Package: Date/time related PHP Version: 7.2.33 Assigned To: derick Block user comment: N Private report: N New Comment: > Is there any chance to revert this change? No. See the related discussion on Github[1] for the reasons and some possible workarounds. [1] <https://github.com/php/php-src/pull/9174#issuecomment-1203744010>ff Previous Comments: ------------------------------------------------------------------------ [2022-12-09 15:49:22] radek0410 at gmail dot com Current solution broke our code because in loop we pass current date to another method where property is typed to our class. Our object only enrich DateTimeImmutable with some methods like: isFirstDayOfAWeek, getStartOfNextWeek, getEndOfSundayThisWeek. Contructor is not overwritten so everything worked well. Is there any chance to revert this change? ------------------------------------------------------------------------ [2022-07-28 10:49:17] git@php.net Automatic comment on behalf of derickr Revision: https://github.com/php/php-src/commit/001e7dbb044fd77a5f771043541dfaa3d3dc8435 Log: Fixed bug #80047 (DatePeriod doesn't warn with custom DateTimeImmutable) ------------------------------------------------------------------------ [2022-07-25 11:38:21] cmb@php.net > The DateTime/DateTimeImmutable classes should have been "final", […] I agree. So maybe we should be consequent, and deprecate subclassing these classes, and make them final in the future. Overall, that might still be better than having *some* restrictions, and sometimes strange behavior. ------------------------------------------------------------------------ [2022-07-25 10:47:14] derick@php.net Hi Kyle, That *now* was meant to be *not* in my text. There are a few issues here: - PHP can't return your original class, as calling userland constructors from internals land constructors is not reliable. - The DateTime/DateTimeImmutable classes should have been "final", which would have meant Carbon and others should have used composition instead of inheritance. - Casting to the "source" class isn't really the right solution either, but indeed probably the best one (although not really 100% accurate either, of course) — and it would also probably break BC for 8.0/8.1. I would therefore suggest that for 8.0/8.1, I back out this change and replace it with a "cast to original source", but leave it in place for PHP 8.2, as it makes it much more clear that the DatePeriod iterator can't deal with inherited classes. ------------------------------------------------------------------------ [2022-07-24 18:50:35] kylekatarnls at gmail dot com Hi Derick, you say "The fix that I have committed is to *now* allow inherited objects here." but it actually does the opposite, which is not addressing the issue but creating an other one. This change will forbid sub-classes of DateTime/DateTimeImmutable it would be quite tough to handle this breaking change as of PHP 8.2, but if you release in 8.0.22, there is nothing we can do to prevent our libraries doing this not to blow up when users will update PHP (as they won't necessarily update in the same time their libraries, such as Carbon which construct DatePeriod with Carbon instances (sub-classes of DateTime) and so thousands apps that might potentially use this). From Liskov substitution principle (SOLID) accepting a parameter T should mean acceptance of any class implementing T (if it's an interface) or extending T (if it's a class). IMHO, fixing as suggested in this ticket (casting to the source class) would be the only correct fix. If it can't be done, I think we should live with this inconsistent output and users would have to re-create the correct object from the raw DateTime or DateTimeImmutable (this is what we do in Carbon), but restricting the input is far worse. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=80047 -- Edit this bug report at https://bugs.php.net/bug.php?id=80047&edit=1