On 11/12/12 06:59, Herman Radtke wrote:
On Mon, Dec 10, 2012 at 11:39 AM, Ángel González <keis...@gmail.com> wrote:
On 10/12/12 16:18, Nikita Nefedov wrote:
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.
That will make it even more inconsistent.
You have add() and plus() but one changes the object and the other doesn't.
If we were going to rewrite php or the DateTime class, it could be a
good idea to make those methods (or its equivalents) not modify the object.
But I don't think it'd be a win to do such thing now.
Another option is to make an ImmutableDateTime class. The DateTime
class could actually be changed to inherit the ImmutableDateTime
class. The only extensions on the DateTime class would be the mutable
methods.
Would love to see ImmutableDateTime!
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
