On Wed, Feb 20, 2013 at 11:21 AM, Gustavo Lopes <glo...@nebm.ist.utl.pt>wrote:
> 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$<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. > This seems like a reasonable suggestion. If no such compromise can be reached, then I would suggest that the DateTimeImmutable addition be reverted altogether. Looking over the thread it seems that most people agree on the design flaws and those who don't are more or less indifferent about DateTimeImmutable either way (e.g. Stas). I'd prefer to have nothing over having something bad. Nikita
