On Tue, 19 Feb 2013 13:01:18 +0100, Derick Rethans <der...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
