Re: DateTimeImmutable
| From: | Lars Strojny | Date: | Wed, 27 Mar 2013 12:18:16 +0000 |
| Subject: | Re: DateTimeImmutable | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-66828@lists.php.net to get a copy of this message | ||
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 írta:
>>
>> 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.