Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66495
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <a8fd9679a80184bc8717c7f9ec7a3df2@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>
	<51249818.2040308@sugarcrm.com>
	<a8fd9679a80184bc8717c7f9ec7a3df2@nebm.ist.utl.pt>
Date: Wed, 6 Mar 2013 16:50:46 +0100
Message-ID: <CAF+90c-iCVtdeezyBFNp46U==yykb5sAwdyEozL77VnVG39MgA@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=e89a8fb1ed06a7379504d7438d12
Subject: Re: [PHP-DEV] Questions regarding DateTimeImmutable
From: nikita.ppv@gmail.com (Nikita Popov)

--e89a8fb1ed06a7379504d7438d12
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 20, 2013 at 11:21 AM, Gustavo Lopes <glopes@nebm.ist.utl.pt>wrote:

> Em 2013-02-20 10:32, Stas Malyshev escreveu:
>
>  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$<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.
>>
>
> Well, the majority of the code here just calls ->format() (which may very
> well be considered a point in your favor). But again most of the time an
> operation with side effects is called, there's no assignment. I also went
> through the first pages and saw one instance of an operation with side
> effects with assignment and three others without (setTime, setTimestamp and
> setTimeZone).
>
> It's very tedious to go through this because most that don't just call
> format just set a field with it. This is potentially dangerous, of course,
> depending on what's further done with the field.
>
> In any case, this seems like a pointless exercise. The solution is simple:
> separate the classes and provide a toDateTime() on DateTimeImmutable for
> interoperability purposes. One wouldn't need to go through Atom libraries
> code to know this is a solution that can't cause problems.
>

This seems like a reasonable suggestion.

If no such compromise can be reached, then I would suggest that the
DateTimeImmutable addition be reverted altogether. Looking over the thread
it seems that most people agree on the design flaws and those who don't are
more or less indifferent about DateTimeImmutable either way (e.g. Stas).
I'd prefer to have nothing over having something bad.

Nikita

--e89a8fb1ed06a7379504d7438d12--