Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66040
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 74.125.82.170 cause and error)
MIME-Version: 1.0
In-Reply-To: <51249818.2040308@sugarcrm.com>
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>
	<51249818.2040308@sugarcrm.com>
Date: Wed, 20 Feb 2013 10:47:29 +0100
Message-ID: <CAEPJdumuUtimU73xgFwf5erp2ptp07onxKhWjr=kp+b7fnybYA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Gustavo Lopes <glopes@nebm.ist.utl.pt>, Derick Rethans <derick@php.net>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04426a22b0987004d624d814
Subject: Re: [PHP-DEV] Questions regarding DateTimeImmutable
From: kontakt@beberlei.de (Benjamin Eberlei)

--f46d04426a22b0987004d624d814
Content-Type: text/plain; charset=ISO-8859-1

People are not using modify() in this way, because they have been bitten
before I would suppose.

What i find important about the DateTime vs DateTimeImmutable is the
expectations I have with regard to how they work with internal state.

If i have a typehint for DateTime, i clone the object before working on it.
If I have a typehint for DateTimeImmutable, i just start using it.

This means the usage patterns for both objects will look very different.
Also for example, the following code is not possible without instanceof
checks:

function thirtyDaysLater(DateTime $dt)
{
    $later = clone $dt;
    $later->modify("+30 day");

    return $later;
}

If i pass a DateTimeImmutable in there, the code will not work.

Imho its not about people are not using it this way in open source code,
its about creating a very likely source of bugs of the ugly to debug kind.


On Wed, Feb 20, 2013 at 10:32 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
> > 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.
>
> If I know what the code does with dates, I don't need to review it.
>
> > 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.
>
> This is true. That's why I want to see what is more probable - that
> library accepts DateTime and would be fine with DateTimeImmutable or
> that library accepts DateTime and would have to be rewritten to work
> with DateTimeImmutable.
>
> > Here is some data:
> >
> >
> 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.
>
> This isn't really a good data since most of this code creates its own
> DateTime and thus there's very little relevancy to what we're talking
> about. If you look up the functions that actually accept DateTime:
>
>
> http://code.google.com/codesearch#search/&type=cs&q=DateTime%5Cs%5C$%20lang:%5Ephp$
>
> the picture would be quite different. I scanned through first 5 pages
> and couldn't find a function that actually calls modify() on DateTime
> object it receives.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--f46d04426a22b0987004d624d814--