So there had been at least two or three messages (subjects) about DateTime
object and everytime there was this problem - people tend to take DateTime
object as mutable object and it really is.
As long as we know, it's not so good - date is immutable by nature. I
don't want to write here why it's so, I will just throw this link:
http://www.ibm.com/developerworks/java/library/j-jtp02183/index.html
I don't want to change any existing functionality, because some people
already use it, but I just wanted to point out that current DateTime class
is forcing people to think about it as mutable.
My main concerns are DateTime#add() and DateTime#sub(). The problem is -
they both change current object and return it.
I think we could add methods to DateTime like add() and sub(), let's say
plus() and minus(), but they would behave differently in the way that they
would return new DateTime objects and won't change current object.
Here's gist to make it clear: https://gist.github.com/4250785
Also, there's methods compareTo, createFromTimestamp and createFromDay, it
could be another proposal. I think we are very often create DateTime
objects just from timestamp or year-month-day. So we could introduce this
methods that could not rely on timelib's parsing, and instead just take
numbers directly.
And I think DateTime lack comparing method. For now I can compare DateTime
objects only by getting their timestamps, but I though that the idea of
DateTime was to go away from using timestamps and instead use well thought
out api.
Anyway, I think this three methods should be considered as another
proposal (because they are solve different problems).
Even if this proposal doesn't go far, I think we should do something with
DateTime. I think I'm going to create user-land library for dealing with
some of this problems.
But if it pass, I will make patch.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
