Re: Questions regarding DateTimeImmutable

On Tue, 19 Feb 2013 13:01:18 +0100, Derick Rethans <derick@php.net> wrote:

On Fri, 15 Feb 2013, Sanford Whiteman wrote:

I think it was done to ease adoption even though it was known to violate LSP. To quote Stas, "As for established practice, everybody expects DateTime, so IMHO we should leave DateTime as base class even though it's not strictly OO-pure."

This is not a matter of some abstract OO-pureness. The problem with the argument that "everybody 'typehints' DateTime; we should inherit from it so that the code will run when the pass it a DateTimeImmutable" is that it assumes that everybody who typehints DateTime uses DateTime in a manner compatible with DateTimeImmutable. I don't believe that no one relies on DateTime method's side effects -- I certainly do.

This way does let users sub in DateTimeImmutable more easily and patch over a ton of unintended -- maybe not even fully noted or understood -- defects in their apps? I dunno.

The argument is that people are using DateTime as if it were immutable and you can now fix this wrong code by passing a DateTimeImmutable instead? I find it highly unlikely.

Yes, that's exactly the idea.

IMO, the classes should not be part of the same hierarchy. If it doesn't matter whether a DateTime or a DateTimeImmutable is passed, then don't typehint. An advantage of PHP is that you can use duck typing. If you do typehint, but then the subclasses break the post-conditions... what's the point? Even if most people DO use DateTime in a compatible way, this is a very myopic way to advance the language or handle a transition. If the DateTimeImmutable interface is superior, people will move to it. If it's important for functions to accept both (I don't think it is), a common superclass with weaker guarantees can be extracted. -- Gustavo Lopes