People are not using modify() in this way, because they have been bitten
before I would suppose.
What i find important about the DateTime vs DateTimeImmutable is the
expectations I have with regard to how they work with internal state.
If i have a typehint for DateTime, i clone the object before working on it.
If I have a typehint for DateTimeImmutable, i just start using it.
This means the usage patterns for both objects will look very different.
Also for example, the following code is not possible without instanceof
checks:
function thirtyDaysLater(DateTime $dt)
{
$later = clone $dt;
$later->modify("+30 day");
return $later;
}
If i pass a DateTimeImmutable in there, the code will not work.
Imho its not about people are not using it this way in open source code,
its about creating a very likely source of bugs of the ugly to debug kind.
On Wed, Feb 20, 2013 at 10:32 AM, Stas Malyshev <smalys...@sugarcrm.com>wrote:
> Hi!
>
> > 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.
>
> If I know what the code does with dates, I don't need to review it.
>
> > 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.
>
> This is true. That's why I want to see what is more probable - that
> library accepts DateTime and would be fine with DateTimeImmutable or
> that library accepts DateTime and would have to be rewritten to work
> with DateTimeImmutable.
>
> > Here is some data:
> >
> >
> 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.
>
> This isn't really a good data since most of this code creates its own
> DateTime and thus there's very little relevancy to what we're talking
> about. If you look up the functions that actually accept DateTime:
>
>
> http://code.google.com/codesearch#search/&type=cs&q=DateTime%5Cs%5C$%20lang:%5Ephp$
>
> the picture would be quite different. I scanned through first 5 pages
> and couldn't find a function that actually calls modify() on DateTime
> object it receives.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
