Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64261
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.163 as permitted sender)
Message-ID: <50C769AF.6020603@sugarcrm.com>
Date: Tue, 11 Dec 2012 09:13:19 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Nikita Nefedov <inefedor@gmail.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <op.wo3wsgnzc8onze@debian-nnefedov.local> <50C69191.5020201@sugarcrm.com> <op.wo490acvc9evq2@debian-nnefedov.local>
In-Reply-To: <op.wo490acvc9evq2@debian-nnefedov.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] DateTime improvement
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> 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.

You need not be aware of anything unless your database identifies dates
by object identities, which is usually wrong since DateTime is a value
type in most systems, and should be identified by value, as I already
noted. If your data are mutable (which I assume they are, since
otherwise the question of saving would not arise), you have to treat
changes in title, body, etc. fields - treat the changes in createdAt
field the same way.

> 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.

It is true that createFromFormat and other factory methods could use an
extension that allows to instantiate child classes, however working
around it is pretty trivial, not sure what "hell" begins there.

> 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.

Yes, but what's wrong with that? It works just fine.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227