Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66822
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
Sender: mike.php.net@gmail.com
Date: Tue, 26 Mar 2013 20:29:07 +0100
Message-ID: <CALJZF3gDDXauR_uzjLfzH5PoLw3w_wEqOso1DWr2mtJp+kfPCA@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: DateTimeImmutable
From: mike@php.net (Michael Wallner)

Hi all!

I am concerned by the introduction of DateTimeImmutable extending
DateTime, and despite not being the talking guy, I'll try to outline
the reasons why I and obviously a lot of other people think so.

I can understand the frustration with a DateTime that should not have
been modifiable in the first place and the wish to improve upon things
and to lead users to the proper way. But, this is not the right way.

If interoperability was in mind, it will not be given, because every
single API which has been written in the last seven years and has
DateTime in it's signature is potentially broken.  The code may and
should be able to expect a modifiable instance of DateTime, which is
no longer guaranteed.

The argument, that it was implemented this way, so that method
signatures do not have to be changed, is weak, because every method
has to be reviewed, and a method signature change would actually be
the right thing to accept a DateTimeImmutable, because it does not act
like a DateTime.

It will lead to lots of boilerplate typechecking code with instanceof
because it actually is not the same type. DateTimeImmutable extending
DateTime will instantly create BC issues, which we will suffer from a
long time.

The toughtful developer, which already cloned the DateTimes in his
methods won't benefit either, because now he's cloning
DateTimeImmutables.

In my opinion, the only way to "solve" this issue is through
documentation, advocation, publication and providing DateTimeImmutable
as a sibling to DateTime.

DateTime is here, and we cannot go back in time, but we might
deprecate DateTime* and introduce a date namespace in PHP-next to
clean up this front, but this already goes beyond the issue with
DateTimeImmutable.


-- 
Regards,
Mike