Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66035
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 74.125.82.44 cause and error)
MIME-Version: 1.0
In-Reply-To: <ba859be22dbf2af5a6fc4b415eec905c@nebm.ist.utl.pt>
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>
	<op.wsr0bvpdidpuyk@damnation.nl.lo.geleia.net>
	<51248C24.4070609@sugarcrm.com>
	<ba859be22dbf2af5a6fc4b415eec905c@nebm.ist.utl.pt>
Date: Wed, 20 Feb 2013 10:16:08 +0100
Message-ID: <CAEPJdu=P2Fw789jbb-Gb49hkva7--100Zs5V44AhXocUKP9L1w@mail.gmail.com>
To: Gustavo Lopes <glopes@nebm.ist.utl.pt>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, Derick Rethans <derick@php.net>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d043be21c8f002804d624684d
Subject: Re: [PHP-DEV] Questions regarding DateTimeImmutable
From: kontakt@beberlei.de (Benjamin Eberlei)

--f46d043be21c8f002804d624684d
Content-Type: text/plain; charset=ISO-8859-1

The problem with DateTimeImmutable extends DateTime is, that the client
code not just magically works with immutable date times, it also works
differently with regard to state, so this will be a source of subtle and
annoying bugs. See the following example:

https://gist.github.com/beberlei/4994193

The client code actually has to know if the instance is DateTime or
DateTimeImmutable and behave differently. Or just use "clone" as before,
and then there is no difference to pre 5.5 code anyways.


On Wed, Feb 20, 2013 at 10:07 AM, Gustavo Lopes <glopes@nebm.ist.utl.pt>wrote:

> Em 2013-02-20 9:41, Stas Malyshev escreveu:
>
>  There's nothing that "everybody" is
>> doing - there are tons of different usage patterns, some of them common,
>> some incompatible. We need to look on what is more probable - that
>> people use DateTime as hint for operations that do not modify the
>> incoming object or that they do modify it and also would put
>> DateTimeImmutable in this code.
>>
>
> No, we do not need to look on what is more probable. It's only when we
> select this very ill-advised option, that we need to start guessing if
> people used all the guarantees of DateTime (namely its side-effects) or not.
>
>
>  So on one side we have existing code that would not accept
>> DateTimeImmutable without extensive modification,
>>
>
> To "accept a DateTimeImmutable" is not the same as "no recoverable fatal
> error when a DateTimeImmutable is passed". You can't possibly know whether
> passing a DateTimeImmutable is safe without reviewing the code on all the
> call hierarchy starting from where your DateTimeImmutable is passed.
>
>
>  unless we create the
>> inheritance, on the other side we have some code that modifies DateTime
>> and should be protected from passing DateTimeImmutable - but there's no
>> such code yet since nobody passes DateTimeImmutable anywhere yet, so we
>> don't make any problem for existing code.
>>
>
> "[C]ode that modifies DateTime and should be protected from passing
> DateTimeImmutable" DOES exist already. Saying that it's not a problem for
> existing code because no one passes DateTimeImmutable is a misleading
> statement -- it assumes codebases exist in isolation. But current libraries
> that take DateTime will still be used in 5.5; in fact, that's the basis of
> your whole argument for this choice.
>
>
>  I find it highly likely that majoirty of DateTime users don't care if
>> it's mutable or not since they either don't change it (most frequent use
>> case) or use something like $foo = $bar->modify("+1 day"); and never
>> rely on the fact that $bar was modified. Of course, I have no data about
>> how many but I find it highly likely that many users simply don't care
>> about the difference.
>>
>
> Here is some data:
>
> http://code.google.com/**codesearch#search/&q=%5C$date-**
> %3Emodify%20lang:php&type=cs&**sq=<http://code.google.com/codesearch#search/&q=%5C$date-%3Emodify%20lang:php&type=cs&sq=>
>
> As you can see, your assumption is false. In the majority of cases, there
> is no assignment.
>
> --
> Gustavo Lopes
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--f46d043be21c8f002804d624684d--