Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65893
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.153 as permitted sender)
Message-ID: <51201696.6080604@sugarcrm.com>
Date: Sat, 16 Feb 2013 15:30:30 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Nikita Popov <nikita.ppv@gmail.com>
CC: PHP internals <internals@lists.php.net>
References: <CAF+90c9corAaNo_ksDU+L99NtQ-Oa86e+tGP9=x09x6CUvdzZA@mail.gmail.com>
In-Reply-To: <CAF+90c9corAaNo_ksDU+L99NtQ-Oa86e+tGP9=x09x6CUvdzZA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Questions regarding DateTimeImmutable
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> a) The DateTimeImmutable class extends the DateTime class. Why was this
> done this way? Both classes are incompatible (as in the inheritance

They're not really "incompatible". Functions that do not modify dates
would work just fine. So it's "not 100% compatible", which is not the
same as incompatible. Of course, we could instead create
DateTimeBaseAbstractClass, but IMHO rewriting all your code to support
it wouldn't be worth the trouble for 99.9% of the code, so what would
end up happening that nobody could use  DateTimeImmutable with any
existing code that expects DateTime. I personally don't see much point
in DateTimeImmutable anyway (immutable data structures are very
important for concurrent programs but for PHP I don't see much benefit)
but if people need it, fine. But ask yourself a question - do you really
want to rewrite every library that accepts DateTime as an argument in
order to use DateTimeImmutable?

> 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?)

I don't see how it's so hard to grasp - it sets time and returns the
modified object. I can't believe you genuinely don't understand how it
works. I have a feeling this "confusing" argument in getting somewhat
stale: PHP users - especially those that want to use specially designed
classes that are useable only in context of design of non-trivial
complexity - have sufficient brain capacity to understand what setTime
could do. And if they absolutely can't, they can to the unthinkable -
read the manual.
So I can see the LSP argument - but "confusing" argument really doesn't
seem to apply here.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227