Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65929
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
Date: Tue, 19 Feb 2013 12:00:34 +0000 (GMT)
To: Nikita Popov <nikita.ppv@gmail.com>
cc: PHP internals <internals@lists.php.net>
In-Reply-To: <CAF+90c9corAaNo_ksDU+L99NtQ-Oa86e+tGP9=x09x6CUvdzZA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1302191153390.5054@whisky.home.derickrethans.nl>
References: <CAF+90c9corAaNo_ksDU+L99NtQ-Oa86e+tGP9=x09x6CUvdzZA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] Questions regarding DateTimeImmutable
From: derick@php.net (Derick Rethans)

On Fri, 15 Feb 2013, Nikita Popov wrote:

> for PHP 5.5 a new DateTimeImmutable class was introduced, which is a 
> variant of DateTime, which has methods working on a clone of the 
> original object.
> 
> There was no RFC on this and some of the design decisions are a bit 
> uncleared to me, so I figured I'd write a mail:
> 
> a) The DateTimeImmutable class extends the DateTime class. Why was 
> this done this way? Both classes are incompatible (as in the 
> inheritance violates LSP). E.g. if you hint against DateTime, then 
> passing in DateTimeImmutable will not work (as the behavior is 
> different). The same also applies the other way around (DateTime 
> extending DateTimeImmutable). Imho a mutable and an immutable variant 
> of a class can't reasonably extend from one another, so I'm not sure 
> why this was done.

It was mostly done so that methods and code accepting do not need 
signature changes. In many cases library code would accept a DateTime, 
call modify and return the changed object - not realizing that the 
original object was changed as well causes issues with calling code. By 
having DateTimeImmutable extend DateTime they can continue to pass them 
in, without having to change library code at all.

> b) The DateTimeImmutable class is (method-wise) an exact copy of 
> DateTime. This makes for some rather weird method names for an 
> immutable object. E.g. there is DateTimeImmutable::modify, which to me 
> seems quite contradictory. There are also a lot of methods of the 
> DateTimeImmutable::setTime form, which also seems rather odd and 
> confusing (how can I set something on an immutable object?)

It just returns the changed object instead of changing the object itself 
*and* returning the changed object (as DateTime does).

cheers,
Derick