Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66824
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CALJZF3gDDXauR_uzjLfzH5PoLw3w_wEqOso1DWr2mtJp+kfPCA@mail.gmail.com>
References: <CALJZF3gDDXauR_uzjLfzH5PoLw3w_wEqOso1DWr2mtJp+kfPCA@mail.gmail.com>
Date: Wed, 27 Mar 2013 09:03:00 +0100
Message-ID: <CAH-PCH7NsNqoKiYOf=FO=jT9Cu5XPM-tVb6n-SATjyU3b51tWw@mail.gmail.com>
To: Michael Wallner <mike@php.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=14dae93408a57c7f6e04d8e37743
Subject: Re: [PHP-DEV] DateTimeImmutable
From: tyra3l@gmail.com (Ferenc Kovacs)

--14dae93408a57c7f6e04d8e37743
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2013.03.26. 20:29, "Michael Wallner" <mike@php.net> ezt =C3=ADrta:
>
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

would it make sense to introduce an interface wich both DateTime and
DateTimeImmutable implements?
that way you can typehint for both if you know that both classes are fine
for you.

--14dae93408a57c7f6e04d8e37743--