Em 2013-02-20 10:32, Stas Malyshev escreveu:
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.
Well, the majority of the code here just calls ->format() (which may
very well be considered a point in your favor). But again most of the
time an operation with side effects is called, there's no assignment. I
also went through the first pages and saw one instance of an operation
with side effects with assignment and three others without (setTime,
setTimestamp and setTimeZone).
It's very tedious to go through this because most that don't just call
format just set a field with it. This is potentially dangerous, of
course, depending on what's further done with the field.
In any case, this seems like a pointless exercise. The solution is
simple: separate the classes and provide a toDateTime() on
DateTimeImmutable for interoperability purposes. One wouldn't need to go
through Atom libraries code to know this is a solution that can't cause
problems.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
