Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64248
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "Stas Malyshev" <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
References: <op.wo3wsgnzc8onze@debian-nnefedov.local>
 <50C69191.5020201@sugarcrm.com>
Date: Tue, 11 Dec 2012 13:01:12 +0400
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <op.wo490acvc9evq2@debian-nnefedov.local>
In-Reply-To: <50C69191.5020201@sugarcrm.com>
User-Agent: Opera Mail/12.11 (Linux)
Subject: Re: [PHP-DEV] DateTime improvement
From: inefedor@gmail.com ("Nikita Nefedov")

Hi!

> Date is immutable, but there's no reason why date object should be able
> to represent only one date. Reference to Java is not exactly applicable
> here, as many problems existing in Java (thread safety, long-living
> object references, etc.) do not exist in PHP.

Say we have a blog post entity, it looks like this:
Post Object
(
     [title] => Qwerty
     [body] => Lorem ipsum
     [craetedAt] => DateTime Object
         (
             [date] => 2010-10-23 00:00:00
             [timezone_type] => 3
             [timezone] => Europe/Moscow
         )
)

Now we have some third-party service that we need to use to send our post  
somewhere, it has a method that accepts title, body and DateTime object  
when the post was created. So we pass our DateTime object to that method  
and it can do with that object whatever it wants. When our script ends, it  
tries to persist all changes to entities and this date will end up in the  
database.
Or we can watch at that problem from ORM's side - when it fetches rows and  
maps them to objects, it should "remember" original state of that data, so  
it can distinguish what objects need to be UPDATE-d in database in the  
end. So there's to ways for ORM to think about dates - as  
strings/timestamps (it could be database's representation of date like  
"2010-10-23" or just integer with timestamp) or it could be objects of  
DateTime. More efficient and logical way would be objects, but that way  
you must aware users that they shouldn't modify values of DateTime  
objects, and instead they should create new instance when they want to  
change value of datetime type. And it's just bad that there could be  
situations when the entity will represent different data, after  
persisting, than database.

> It does not - if you don't need it mutable, don't use modify() or
> override modify() with method that would clone the object and return
> modified clone. This can easily be done in userspace if you require an
> immutable object, which most of the users actually do not.

I was speaking not about modify() but about add() and sub(). Actually I  
don't like these two methods (plus and minus) that I proposed too, but how  
can we solve this problem differently?

What about user-land implementation - there's one problem: I can't just  
extend DateTime object, because it has factory methods like  
createFromFormat, so I need to use decorator pattern and from that point  
hell begins.

> Timestamp doesn't need any timelib parsing AFAIK, but YMD certainly does
> - you need to calculate the actual timestamp according to current
> timezone, etc.

I meant I must either call create new DateTime and pass to constructor  
timestamp string starting with @ (and there would be parsing involved) or  
call createFromFormat and pass "U" as second parameter and timestamp as  
first one.

> DateTime objects can be compared directly, why do you think you can
> compare only timestamps?

My fault, didn't know about that.