Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65901
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 209.85.212.176 cause and error)
MIME-Version: 1.0
In-Reply-To: <51201696.6080604@sugarcrm.com>
References: <CAF+90c9corAaNo_ksDU+L99NtQ-Oa86e+tGP9=x09x6CUvdzZA@mail.gmail.com>
	<51201696.6080604@sugarcrm.com>
Date: Sun, 17 Feb 2013 17:21:55 +0100
Message-ID: <CAEPJdunTRn-qu1dK6-a1p3E-0YqWCU8mmWG18L5cyDiWyKgv=g@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d043c80dac65d2e04d5ee0197
Subject: Re: [PHP-DEV] Questions regarding DateTimeImmutable
From: kontakt@beberlei.de (Benjamin Eberlei)

--f46d043c80dac65d2e04d5ee0197
Content-Type: text/plain; charset=ISO-8859-1

Hey,

would it be possible for DateTime and DateTimeImmutable to not extend each
other at all and be two seperate classes?

greetings,
Benjamin


On Sun, Feb 17, 2013 at 12:30 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--f46d043c80dac65d2e04d5ee0197--