Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66828
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain strojny.net from 46.4.40.248 cause and error)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
In-Reply-To: <CAH-PCH7NsNqoKiYOf=FO=jT9Cu5XPM-tVb6n-SATjyU3b51tWw@mail.gmail.com>
Date: Wed, 27 Mar 2013 13:18:16 +0100
Cc: Michael Wallner <mike@php.net>,
  PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <BEE73C11-F582-4A80-84B2-97D1800CB002@strojny.net>
References: <CALJZF3gDDXauR_uzjLfzH5PoLw3w_wEqOso1DWr2mtJp+kfPCA@mail.gmail.com> <CAH-PCH7NsNqoKiYOf=FO=jT9Cu5XPM-tVb6n-SATjyU3b51tWw@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Subject: Re: [PHP-DEV] DateTimeImmutable
From: lars@strojny.net (Lars Strojny)

Not really, as an interface guarantees behavior, which is not possible =
for DateTimeImmutable and DateTime.

Am 27.03.2013 um 09:03 schrieb Ferenc Kovacs <tyra3l@gmail.com>:

> 2013.03.26. 20:29, "Michael Wallner" <mike@php.net> ezt =EDrta:
>>=20
>> Hi all!
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> The toughtful developer, which already cloned the DateTimes in his
>> methods won't benefit either, because now he's cloning
>> DateTimeImmutables.
>>=20
>> In my opinion, the only way to "solve" this issue is through
>> documentation, advocation, publication and providing =
DateTimeImmutable
>> as a sibling to DateTime.
>>=20
>> 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.
>>=20
>>=20
>> --
>> Regards,
>> Mike
>>=20
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>=20
>=20
> 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.