The problem with DateTimeImmutable extends DateTime is, that the client code not just magically works with immutable date times, it also works differently with regard to state, so this will be a source of subtle and annoying bugs. See the following example:
https://gist.github.com/beberlei/4994193 The client code actually has to know if the instance is DateTime or DateTimeImmutable and behave differently. Or just use "clone" as before, and then there is no difference to pre 5.5 code anyways. On Wed, Feb 20, 2013 at 10:07 AM, Gustavo Lopes <glo...@nebm.ist.utl.pt>wrote: > Em 2013-02-20 9:41, Stas Malyshev escreveu: > > There's nothing that "everybody" is >> doing - there are tons of different usage patterns, some of them common, >> some incompatible. We need to look on what is more probable - that >> people use DateTime as hint for operations that do not modify the >> incoming object or that they do modify it and also would put >> DateTimeImmutable in this code. >> > > No, we do not need to look on what is more probable. It's only when we > select this very ill-advised option, that we need to start guessing if > people used all the guarantees of DateTime (namely its side-effects) or not. > > > So on one side we have existing code that would not accept >> DateTimeImmutable without extensive modification, >> > > To "accept a DateTimeImmutable" is not the same as "no recoverable fatal > error when a DateTimeImmutable is passed". You can't possibly know whether > passing a DateTimeImmutable is safe without reviewing the code on all the > call hierarchy starting from where your DateTimeImmutable is passed. > > > unless we create the >> inheritance, on the other side we have some code that modifies DateTime >> and should be protected from passing DateTimeImmutable - but there's no >> such code yet since nobody passes DateTimeImmutable anywhere yet, so we >> don't make any problem for existing code. >> > > "[C]ode that modifies DateTime and should be protected from passing > DateTimeImmutable" DOES exist already. Saying that it's not a problem for > existing code because no one passes DateTimeImmutable is a misleading > statement -- it assumes codebases exist in isolation. But current libraries > that take DateTime will still be used in 5.5; in fact, that's the basis of > your whole argument for this choice. > > > I find it highly likely that majoirty of DateTime users don't care if >> it's mutable or not since they either don't change it (most frequent use >> case) or use something like $foo = $bar->modify("+1 day"); and never >> rely on the fact that $bar was modified. Of course, I have no data about >> how many but I find it highly likely that many users simply don't care >> about the difference. >> > > Here is some data: > > http://code.google.com/**codesearch#search/&q=%5C$date-** > %3Emodify%20lang:php&type=cs&**sq=<http://code.google.com/codesearch#search/&q=%5C$date-%3Emodify%20lang:php&type=cs&sq=> > > As you can see, your assumption is false. In the majority of cases, there > is no assignment. > > -- > Gustavo Lopes > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
