Stas Malyshev <smalys...@sugarcrm.com> писал(а) в своём письме Tue, 11 Dec
2012 21:06:05 +0400:
Hi!
As Nikita says, from an ORM perspective, an object is always immutable
(at least with current implementations I know of), and that's because
they can simply use the object hashes to identify two different objects.
Why for ORM Date is even an object? In most databases, date is a basic
value type, and should be accepted by value, not as a complex object.
So, it should also be identified as the value - for number 1, you do not
need additional identity or hash except it being number 1, same should
be for dates.
Then why do we even need DateTime class? We could stay with functions. I
think if we want to bring some OOP in php, then we need to do it right way.
I don't believe (at all) in "if you don't need it mutable, don't use
modify() oroverride modify()". If the API is there, people will use it.
We tried to implement an immutable DateTime in userland, but it doesn't
work out well...
Why it doesn't work well and why PHP needs to be changed because of it?
Because of some DateTime's limitations - you will end up making brand new
DateTime class, reimplementing *all* the features that were implemented in
DateTime. At first - you can't just extend DateTime, because of
factory-methods - so that way you will need to use decorator, but even
with this approach (pretty shitty approach I must say) there would be
problems with diff() method (if you want to use DateTime's diff, you will
need to implement getDateTime method of your own DateTime class (because
diff accepts DateTime), so you will end with mutable object again, because
one can just execute $yourDate->getDateTime()->modify(*whatever you
want*)).
I think it should be changed (or implemented another one, like someone
said, DateTimeImmutable) because date is atomic value.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
