Implemented request #71520 (Adding the DateTime constants to the DateTimeInterface interface)

[Majkl578]

Implements FR #71520.

The primary motivation should be obvious from the feature request. Currently it's not possible to properly use DateTimeImmutable formatting, because one needs to use DateTime anyway, since the constants are defined only on DateTime class.

[nikic]

Note that this change is technically BC breaking, because constants defined in interfaces cannot be overridden. I don't think that's a blocker for landing in master though.

[derickr]

Code looks good, but I'd split up the test cases.

[derickr]

Instead of adding to this test case, I think the additions should go into a new test case (or test cases).

[Majkl578]

Made a separate test for each of DateTime/DateTimeImmutable/DateTimeInterface.

[Fleshgrinder]

Note that this change is technically BC breaking, because constants defined in interfaces cannot be overridden. I don't think that's a blocker for landing in master though.

It does result in a fatal error thought, not sure how common it is that people define these constants themselves in their extending classes. The problem is, that any library that does will have a hard time working around this.

[Majkl578]

Updated.

constants defined in interfaces cannot be overridden

It does result in a fatal error

Interesting, because the following code works just fine...

<?php

class Foo extends DateTimeImmutable
{
        const W3C = 'Y';
}

echo DateTimeInterface::W3C, PHP_EOL; // Y-m-d\TH:i:sP
echo Foo::W3C, PHP_EOL; // Y

[nikic]

@Majkl578 Heh, https://3v4l.org/V7DiV vs https://3v4l.org/JZBZg. Looks like the check only kicks in if you change it directly in the class that implements the interface, but not if there's at least one class in between. So looks like this isn't a BC break after all.

[nikic]

Merged as 637714c into master. Thanks!

[Fleshgrinder]

@Majkl578 not sure why that is the case, probably because an interface that is defined internally behaves differently than an interface in userland: https://3v4l.org/bNRQu This is of course bad, very bad in this case, but would change the game for this PR in terms of being a breaking change.

[Majkl578]

@Fleshgrinder Actually, this seems to be a case pointed out by @nikic - it's only checked for direct descendants, even in user-land. See https://3v4l.org/m5Pfp.

[Fleshgrinder]

Now that’s weird behavior. 😅 Well, in that case this PR will be fine for everybody because it is using other magic to prevent implementation in userland.

[derickr]

This change doesn't seem to be reflected in the documentation yet. See http://php.net/manual/en/class.datetimeinterface.php vs http://php.net/manual/en/class.datetime.php — please fix that.

[cmb69]

Documented via http://svn.php.net/viewvc?view=revision&revision=345663.