DateTimeImmutable

Derick, Release Managers, Rasmus!

I'm seriously concerned by the introduction of DateTimeImmutable extending DateTime, and despite not being the talking guy, I'll try to outline the reasons why I and obviously a lot of other people think so.

I can understand the frustration with a DateTime that should not have been modifiable in the first place and the wish to improve upon things and to lead users to the proper way. But, this is not the right way.

If interoperability was in mind, it will not be given, because every single API which has been written in the last seven years and has DateTime in it's signature is potentially broken.  The code has "the right" to expect a modifiable instance of DateTime, which is no longer guaranteed.

The argument, that it was implemented this way, so that method signatures do not have to be changed, is very weak, because every method has to be reviewed, and a method signature change would actually be the right thing to accept a DateTimeImmutable, because it cannot act like a DateTime.

It will lead to tons of boilerplate typechecking code with instanceof because it actually is not the same type. DateTimeImmutable extending DateTime will instantly create a lot of BC issues, which we will suffer from the next few years.

Even the "nice guy" developer, which already clones the DateTimes in his methods will be shot from behind, because he might be cloning DateTimeImmutables in the future.

In my opinion, the only way to "solve" this issue is through documentation, advocation and publication, but not through a righteous backdoor.

Mike