FAQ
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

Search Discussions

  • Ferenc Kovacs at Mar 27, 2013 at 8:03 am
    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.
  • Lars Strojny at Mar 27, 2013 at 12:18 pm
    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.
  • Jordi Boggiano at Mar 27, 2013 at 12:41 pm

    On 27.03.2013 13:18, Lars Strojny wrote:
    Not really, as an interface guarantees behavior, which is not possible for DateTimeImmutable and DateTime.
    The interface could be a subset of DateTime public methods, including
    only the readonly ones.

    I can't imagine how this could possibly be named in a sane way though :/

    Cheers

    --
    Jordi Boggiano
    @seldaek - http://nelm.io/jordi
  • Andreas Heigl at Mar 27, 2013 at 12:49 pm

    Am 27.03.13 13:41, schrieb Jordi Boggiano:
    On 27.03.2013 13:18, Lars Strojny wrote:
    Not really, as an interface guarantees behavior, which is not possible for DateTimeImmutable and DateTime.
    The interface could be a subset of DateTime public methods, including
    only the readonly ones.

    I can't imagine how this could possibly be named in a sane way though :/
    DateTimeInterface or DateTimeROInterface?

    Cheers
    Cheers

    --
    ,,,
    (o o)
    +---------------------------------------------------------ooO-(_)-Ooo-+
    Andreas Heigl |
    mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
    http://andreas.heigl.org http://hei.gl/wiFKy7 |
    +---------------------------------------------------------------------+
    http://hei.gl/root-ca |
    +---------------------------------------------------------------------+
  • Pierre Joye at Mar 27, 2013 at 1:14 pm

    On Wed, Mar 27, 2013 at 1:49 PM, Andreas Heigl wrote:
    Am 27.03.13 13:41, schrieb Jordi Boggiano:
    On 27.03.2013 13:18, Lars Strojny wrote:
    Not really, as an interface guarantees behavior, which is not possible for DateTimeImmutable and DateTime.
    The interface could be a subset of DateTime public methods, including
    only the readonly ones.

    I can't imagine how this could possibly be named in a sane way though :/
    DateTimeInterface or DateTimeROInterface?

    I'd to re post Lars suggestion from another thread. Do a RFC. This is
    going again in all possible directions and I fear that we will not get
    a good solution at the end of the day.

    Cheers,
    --
    Pierre

    @pierrejoye
  • Ferenc Kovacs at Mar 27, 2013 at 4:10 pm

    On Wed, Mar 27, 2013 at 2:14 PM, Pierre Joye wrote:
    On Wed, Mar 27, 2013 at 1:49 PM, Andreas Heigl wrote:
    Am 27.03.13 13:41, schrieb Jordi Boggiano:
    On 27.03.2013 13:18, Lars Strojny wrote:
    Not really, as an interface guarantees behavior, which is not possible
    for DateTimeImmutable and DateTime.
    The interface could be a subset of DateTime public methods, including
    only the readonly ones.

    I can't imagine how this could possibly be named in a sane way though :/
    DateTimeInterface or DateTimeROInterface?

    I'd to re post Lars suggestion from another thread. Do a RFC. This is
    going again in all possible directions and I fear that we will not get
    a good solution at the end of the day.

    Cheers,
    --
    Pierre

    @pierrejoye

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    agree, but the current implementation shouldn't be shipped until we find an
    acceptable solution.

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Johannes Schlüter at Mar 27, 2013 at 5:05 pm

    On Wed, 2013-03-27 at 17:10 +0100, Ferenc Kovacs wrote:
    agree, but the current implementation shouldn't be shipped until we
    find an acceptable solution.
    +1

    johannes
  • Derick Rethans at Mar 29, 2013 at 9:35 am

    On Wed, 27 Mar 2013, Jordi Boggiano wrote:
    On 27.03.2013 13:18, Lars Strojny wrote:

    Not really, as an interface guarantees behavior, which is not
    possible for DateTimeImmutable and DateTime.
    The interface could be a subset of DateTime public methods, including
    only the readonly ones.

    I can't imagine how this could possibly be named in a sane way though :/
    Name aside, an interface is sort of very useful otherwise we're ending
    up with code like this all over the time:

    first_arg_ce = zend_get_class_entry(start);
    if ((first_arg_ce != date_ce_date) && (first_arg_ce != date_ce_immutable)) {

    And that's a real pain, so an interface for just the gettings (and other
    methods not modifying/changing anything is probably a good idea. I'll
    see if I can work on this over the Easter weekend.

    cheers,
    Derick
  • Steve Clay at Mar 27, 2013 at 2:57 pm

    On 3/26/13 3:29 PM, Michael Wallner wrote:
    I am concerned by the introduction of DateTimeImmutable extending
    DateTime ...
    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. ...
    In my opinion, the only way to "solve" this issue is through
    documentation, advocation, publication and providing DateTimeImmutable
    as a sibling to DateTime.
    Much agreed. DateTimeImmutable is welcomed as a better design, but it is not a clean
    substitute for a DataTime object.


    Steve Clay
  • Derick Rethans at Mar 27, 2013 at 8:53 pm

    On Tue, 26 Mar 2013, Michael Wallner wrote:

    providing DateTimeImmutable as a sibling to DateTime.
    That's fine with me, but I am not having the time to work on a patch
    right now.

    cheers,
    Derick
  • Lars Strojny at Mar 28, 2013 at 9:04 am
    Hi Derick,

    Am 27.03.2013 um 21:53 schrieb Derick Rethans <derick@php.net>:
    On Tue, 26 Mar 2013, Michael Wallner wrote:

    providing DateTimeImmutable as a sibling to DateTime.
    That's fine with me, but I am not having the time to work on a patch
    right now.
    Happens. Let’s revert it till somebody finds some time to do it. Could you revert it?

    cu,
    Lars
  • Nikita Nefedov at Mar 28, 2013 at 9:26 am

    On Thu, 28 Mar 2013 13:04:44 +0400, Lars Strojny wrote:

    Hi Derick,

    Am 27.03.2013 um 21:53 schrieb Derick Rethans <derick@php.net>:
    On Tue, 26 Mar 2013, Michael Wallner wrote:

    providing DateTimeImmutable as a sibling to DateTime.
    That's fine with me, but I am not having the time to work on a patch
    right now.
    Happens. Let’s revert it till somebody finds some time to do it. Could
    you revert it?

    cu,
    Lars
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    Hi,

    Sorry, maybe I missed something, but what the consensus did we achieve
    here?
    Make an interface? Or maybe make an abstract class with constructor, late
    static binded fabric methods (which btw could solve problems with making
    custom datetime class in userland), and some of the methods like diff and
    so on? Or maybe something else?

    PS I think I can make a patch on these weekends.
  • Lester Caine at Mar 28, 2013 at 9:58 am

    Nikita Nefedov wrote:
    Sorry, maybe I missed something, but what the consensus did we achieve here?
    Make an interface? Or maybe make an abstract class with constructor, late static
    binded fabric methods (which btw could solve problems with making custom
    datetime class in userland), and some of the methods like diff and so on? Or
    maybe something else?
    I think that the general consensus is that this needs to have a proper RFC
    generated and all the ramifications investigated properly? It's not the '5
    minute fix' that was originally thought. When DateTime was first added it caused
    a lot of problems simply because there were/are other library elements doing the
    same job and clashing. This is perhaps an area where the original design was the
    problem since many people seem to think that it was wrong, so 'correcting' it
    needs proper consideration?

    --
    Lester Caine - G8HFL
    -----------------------------
    Contact - http://lsces.co.uk/wiki/?page=contact
    L.S.Caine Electronic Services - http://lsces.co.uk
    EnquirySolve - http://enquirysolve.com/
    Model Engineers Digital Workshop - http://medw.co.uk
    Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
  • Derick Rethans at Mar 28, 2013 at 11:05 am

    On Thu, 28 Mar 2013, Lars Strojny wrote:

    Am 27.03.2013 um 21:53 schrieb Derick Rethans <derick@php.net>:
    On Tue, 26 Mar 2013, Michael Wallner wrote:

    providing DateTimeImmutable as a sibling to DateTime.
    That's fine with me, but I am not having the time to work on a patch
    right now.
    Happens. Let’s revert it till somebody finds some time to do it. Could
    you revert it?
    No, let's not revert it.

    cheers,
    Derick
  • Santiago Lizardo at Mar 28, 2013 at 11:09 am
    I'm on my easter holidays and I have some spare time to revert the changes
    introduced by the DateTimeImmutable for you Derick. Please let me know if
    you want me to do it.

    On Thu, Mar 28, 2013 at 12:05 PM, Derick Rethans wrote:
    On Thu, 28 Mar 2013, Lars Strojny wrote:

    Am 27.03.2013 um 21:53 schrieb Derick Rethans <derick@php.net>:
    On Tue, 26 Mar 2013, Michael Wallner wrote:

    providing DateTimeImmutable as a sibling to DateTime.
    That's fine with me, but I am not having the time to work on a patch
    right now.
    Happens. Let’s revert it till somebody finds some time to do it. Could
    you revert it?
    No, let's not revert it.

    cheers,
    Derick

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Derick Rethans at Mar 28, 2013 at 12:18 pm

    On Thu, 28 Mar 2013, Santiago Lizardo wrote:

    I'm on my easter holidays and I have some spare time to revert the changes
    introduced by the DateTimeImmutable for you Derick. Please let me know if
    you want me to do it.
    No, don't revert it. It needs to be a sibling class to DateTime instead
    of inherited like it is now.

    cheers,
    Derick
  • Pierre Joye at Mar 28, 2013 at 11:18 am

    On Thu, Mar 28, 2013 at 12:05 PM, Derick Rethans wrote:
    On Thu, 28 Mar 2013, Lars Strojny wrote:

    Am 27.03.2013 um 21:53 schrieb Derick Rethans <derick@php.net>:
    On Tue, 26 Mar 2013, Michael Wallner wrote:

    providing DateTimeImmutable as a sibling to DateTime.
    That's fine with me, but I am not having the time to work on a patch
    right now.
    Happens. Let’s revert it till somebody finds some time to do it. Could
    you revert it?
    No, let's not revert it.
    I'd rather revert until a consensus is reached. Having a sub optimal
    solution, at best, only because one or more developers did not get the
    time to sit down on it is not going to be a good way to get new
    features in php.

    Can't make it for 5.5? 5.6 is in around a year, we lived years without
    this, we can wait one more year.

    Cheers,
    --
    Pierre

    @pierrejoye

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMar 26, '13 at 7:29p
activeMar 29, '13 at 9:35a
posts18
users12
websitephp.net

People

Translate

site design / logo © 2022 Grokbase