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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
