Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66002
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.21 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "Sanford Whiteman" <swhitemanlistens-software@cypressintegrated.com>,
 "Derick Rethans" <derick@php.net>
Cc: "Nikita Popov" <internals@lists.php.net>
References: <CAF+90c9corAaNo_ksDU+L99NtQ-Oa86e+tGP9=x09x6CUvdzZA@mail.gmail.com> <1867201214.20130215192512@cypressintegrated.com> <alpine.DEB.2.02.1302191200530.5054@whisky.home.derickrethans.nl>
Date: Wed, 20 Feb 2013 00:17:45 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_I=2ES=2ET=2E?=
Message-ID: <op.wsr0bvpdidpuyk@damnation.nl.lo.geleia.net>
In-Reply-To: <alpine.DEB.2.02.1302191200530.5054@whisky.home.derickrethans.nl>
User-Agent: Opera Mail/12.12 (Linux)
Subject: Re: [PHP-DEV] Questions regarding DateTimeImmutable
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

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