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
