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. -- Herman Radtke hermanrad...@gmail.com | http://hermanradtke.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
