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.
Here's gist to make it clear: https://gist.github.com/4250785
Also, there's methods compareTo, createFromTimestamp and createFromDay, it
could be another proposal. I think we are very often create DateTime
objects just from timestamp or year-month-day. So we could introduce this
methods that could not rely on timelib's parsing, and instead just take
numbers directly.
And I think DateTime lack comparing method. For now I can compare DateTime
objects only by getting their timestamps, but I though that the idea of
DateTime was to go away from using timestamps and instead use well thought
out api.
Anyway, I think this three methods should be considered as another
proposal (because they are solve different problems).
Even if this proposal doesn't go far, I think we should do something with
DateTime. I think I'm going to create user-land library for dealing with
some of this problems.
But if it pass, I will make patch.
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.htmlI 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.
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.htmlI 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
hermanradtke@gmail.com | http://hermanradtke.com
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.htmlI 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.
Would love to see ImmutableDateTime!
David
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.htmlI 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.
Yes, that's horrible - and might not even work with the current design.
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.
I'm not really against that, but we do need to use the Date namespace -
so DateTimeImmutable. It might be trickier to do than it sounds
though...
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
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.I'm not really against that, but we do need to use the Date namespace -
so DateTimeImmutable. It might be trickier to do than it sounds
though...
I've started hacking on this - with some luck I'm done before PHP 5.5
beta1.
cheers,
Derick
This is so cool, thanks Derick! If you need help with testing or anything else, let me know.
Am 16.12.2012 um 13:21 schrieb Derick Rethans derick@php.net:
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.I'm not really against that, but we do need to use the Date namespace -
so DateTimeImmutable. It might be trickier to do than it sounds
though...I've started hacking on this - with some luck I'm done before PHP 5.5
beta1.cheers,
Derick
I'm not really against that, but we do need to use the Date namespace -
so DateTimeImmutable. It might be trickier to do than it sounds
though...I've started hacking on this - with some luck I'm done before PHP 5.5
beta1.
Am I missing something here?
Isn't this just making the object content read only?
Haven't we been having a separate discussion on that?
On the whole I'm only using DateTime objects when I need to display the content
in a different timezone, so the timezone needs to be changeable, but the base
date is read only. Alternatively I'm building a calendar so need 'all the days
for month x' as an array, and then use those dates to generate the database
query. If it's a 'local' calendar then there will be a time offset incorporated
as well.
In Firebird, the dates are stored as a numeric value, with the whole part the
number of days, and the fraction the time of day. Two 32bit values. When doing
comparisons there is no point converting to a DateTime object, one converts FROM
the DateTime to parameter suitable for the database, and leave the database to
do the filtering.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
I'm not really against that, but we do need to use the Date namespace -
so DateTimeImmutable. It might be trickier to do than it sounds
though...I've started hacking on this - with some luck I'm done before PHP 5.5
beta1.Am I missing something here?
Isn't this just making the object content read only?
Sortof. But as that is how things work, making an immutable variant
isn't that easy.
Haven't we been having a separate discussion on that?
On the whole I'm only using DateTime objects when I need to display the
content in a different timezone, so the timezone needs to be changeable, but
the base date is read only. Alternatively I'm building a calendar so need 'all
the days for month x' as an array, and then use those dates to generate the
database query. If it's a 'local' calendar then there will be a time offset
incorporated as well.
Al the methods will still return the modified DateTime object - it's
just that the one that you call f.e. ->modify() on won't change
anymore.
cheers,
Derick
Hi!
Al the methods will still return the modified DateTime object - it's
just that the one that you call f.e. ->modify() on won't change
anymore.
Doesn't it mean you can just call clone() on it in modifier methods
before doing anything else?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Al the methods will still return the modified DateTime object -
it's just that the one that you call f.e. ->modify() on won't
change anymore.Doesn't it mean you can just call clone() on it in modifier methods
before doing anything else?
Yeah, I think so. I tried that but I got some errors. It's something for
me to sort out. So far, I've just created all the helper methods etc.
clone() however is not a method, but a language construct... so it's not
that trivial.
cheers,
Derick
Am 16.12.2012 um 13:21 schrieb Derick Rethans derick@php.net:
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.I'm not really against that, but we do need to use the Date
namespace - so DateTimeImmutable. It might be trickier to do than
it sounds though...I've started hacking on this - with some luck I'm done before PHP
5.5 beta1.
This is so cool, thanks Derick! If you need help with testing or
anything else, let me know.
I've just pushed it to the "immutable-date" branch:
http://git.php.net/?p=php-src.git;a=shortlog;h=refs/heads/immutable-date
I went for DateTimePoint. Point as in "Point in time". I am not too
happy with the name, but I think it works better than DateTimeImmutable
as that just sounds quircky. I'm still fixing up a few things and adding
some test cases. I think I need to make it work with DatePeriod too -
but I haven't looked at that yet.
cheers,
Derick
I went for DateTimePoint. Point as in "Point in time". I am not too
happy with the name, but I think it works better than DateTimeImmutable
as that just sounds quircky. I'm still fixing up a few things and adding
some test cases. I think I need to make it work with DatePeriod too -
but I haven't looked at that yet.
some suggestions:
DateTimeValue
DateTimeImmutable
DateImmutable
DateFixed
DateStatic
(and as a bonus: DateTime2)
Hi Derick,
I would go with DateTimeValue or DateTimeImmutable as well.
Am 17.12.2012 um 19:42 schrieb Benjamin Eberlei kontakt@beberlei.de:
I went for DateTimePoint. Point as in "Point in time". I am not too
happy with the name, but I think it works better than DateTimeImmutable
as that just sounds quircky. I'm still fixing up a few things and adding
some test cases. I think I need to make it work with DatePeriod too -
but I haven't looked at that yet.some suggestions:
DateTimeValue
DateTimeImmutable
DateImmutable
DateFixed
DateStatic
(and as a bonus: DateTime2)
I would go with DateTimeValue or DateTimeImmutable as well.
+1. I'd prefer DateTimeImmutable personally because it describes what
it is better than the other options.
Adam "bikeshed" Harvey
I would go with DateTimeValue or DateTimeImmutable as well.
+1. I'd prefer DateTimeImmutable personally because it describes what
it is better than the other options.
That's what I have changed it to now[1]. I've also modified
DatePeriod[2] to allow for immutable objects to be returned. Right now, it will return
DateTimeImmutable objects if the start date object is also
DateTimeImmutable. In case it is a DateTime object, or an ISO8601
date-string, the returned objects are of the DateTime class[3].
Sebastian had responded off-list that he'd rather have DateTime inherit
from DateTimeImmutable, instead of the current variant where
DateTimeImmutable inherits DateTime. While this OO-design principle wise
makes perfect sense, practically it is not as handy. I've played with a
patch to implement it and it works, but lots of messages are now "blah
blah wants a DateTimeImmutable class" instead of "blah blah wants a
DateTime class". Although I think having a DateTimeImmutable is a good
thing, I don't want to confuse too many people (novices!) with weird OO
terms. And in most cases, people don't care whether DateTime is
immutable or not. Besides that, it also made the change and the code
more complex and duplicated. Because of this, I didn't pursue this patch
any further.
[1] http://git.php.net/?p=php-src.git;a=commit;h=6b48ae4580a0e97f7df4f1733eca345755110b96
[2] http://git.php.net/?p=php-src.git;a=commit;h=042ddf371e84fbb7ba1326e7bd45888e63fb30ef
[3] http://git.php.net/?p=php-src.git;a=blob;f=ext/date/tests/date_period-immutable.phpt;h=0ec4b4a13025b9494833aa90fa64be7d95f8a261;hb=042ddf371e84fbb7ba1326e7bd45888e63fb30ef
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
Hi!
Sebastian had responded off-list that he'd rather have DateTime inherit
from DateTimeImmutable, instead of the current variant where
DateTimeImmutable inherits DateTime. While this OO-design principle wise
makes perfect sense, practically it is not as handy. I've played with a
Actually, I would claim it doesn't make "perfect sense", since it would
mean DateTime would violate DateTimeImmutable's contract of being, well,
immutable. Strictly speaking, they can not either extend from other one,
since they have APIs which are not subset of each other. However, doing
it strictly OO would mean getting into Java-esque web of interfaces,
abstract classes and implementation classes, which would suck.
As for established practice, everybody expects DateTime, so IMHO we
should leave DateTime as base class even though it's not strictly OO-pure.
Speaking of derived classes, though, I wonder how hard it would be to
make DateTime factory methods - such as createFromFormat - to be able to
produce instance of child class? Now if you want to extend DateTime and
use those, you need to implement some weird things like:
$dt = DateTime::createFromFormat($format, $time);
$mydt = new MyDateTime("@".$dt->getTimestamp());
Maybe there's a better way but I'm not sure what it is.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Stas Malyshev smalyshev@sugarcrm.com wrote:
Sebastian had responded off-list that he'd rather have DateTime
inherit
from DateTimeImmutable, instead of the current variant where
DateTimeImmutable inherits DateTime. While this OO-design principle
wise
makes perfect sense, practically it is not as handy. I've played
with aActually, I would claim it doesn't make "perfect sense", since it
would
mean DateTime would violate DateTimeImmutable's contract of being,
well,
immutable. Strictly speaking, they can not either extend from other
one,
since they have APIs which are not subset of each other. However,
doing
it strictly OO would mean getting into Java-esque web of interfaces,
abstract classes and implementation classes, which would suck.
As for established practice, everybody expects DateTime, so IMHO we
should leave DateTime as base class even though it's not strictly
OO-pure.Speaking of derived classes, though, I wonder how hard it would be to
make DateTime factory methods - such as createFromFormat - to be able
to
produce instance of child class? Now if you want to extend DateTime
and
use those, you need to implement some weird things like:$dt = DateTime::createFromFormat($format, $time);
$mydt = new MyDateTime("@".$dt->getTimestamp());Maybe there's a better way but I'm not sure what it is.
The above wouldn't quite work as you lose timezone information.
I've thought about this before and we can only do this if we allow to specify the class name as extra argument.
I'd like to add this, but it is a bit unrelated to this change.
Derick
I've seen DateTimeValue used elsewhere for userspace immutable date time
objects. Whether that indicates we SHOULD or SHOULD NOT use that for an
in-C version, I don't know. (I'm inclined to say should-but-namespace,
but I don't know if we're doing that yet.)
Of course, I have no idea if anyone in userspace is using
DateTimeImmutable...
--Larry Garfield
Hi Derick,
I would go with DateTimeValue or DateTimeImmutable as well.
Am 17.12.2012 um 19:42 schrieb Benjamin Eberlei kontakt@beberlei.de:
I went for DateTimePoint. Point as in "Point in time". I am not too
happy with the name, but I think it works better than DateTimeImmutable
as that just sounds quircky. I'm still fixing up a few things and adding
some test cases. I think I need to make it work with DatePeriod too -
but I haven't looked at that yet.some suggestions:
DateTimeValue
DateTimeImmutable
DateImmutable
DateFixed
DateStatic
(and as a bonus: DateTime2)
Of course, I have no idea if anyone in userspace is using
DateTimeImmutable...
Well, it seems unlikely, unless he is Yoda or French.
I mean, in English, it is common to put the adjective in front of the noun,
isn't it?
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/12/20 Larry Garfield larry@garfieldtech.com
I've seen DateTimeValue used elsewhere for userspace immutable date time
objects. Whether that indicates we SHOULD or SHOULD NOT use that for an
in-C version, I don't know. (I'm inclined to say should-but-namespace, but
I don't know if we're doing that yet.)Of course, I have no idea if anyone in userspace is using
DateTimeImmutable...--Larry Garfield
Hi Derick,
I would go with DateTimeValue or DateTimeImmutable as well.
Am 17.12.2012 um 19:42 schrieb Benjamin Eberlei kontakt@beberlei.de:
I went for DateTimePoint. Point as in "Point in time". I am not too
happy with the name, but I think it works better than DateTimeImmutable
as that just sounds quircky. I'm still fixing up a few things and adding
some test cases. I think I need to make it work with DatePeriod too -
but I haven't looked at that yet.some suggestions:
DateTimeValue
DateTimeImmutable
DateImmutable
DateFixed
DateStatic
(and as a bonus: DateTime2)
Of course, I have no idea if anyone in userspace is using
DateTimeImmutable...Well, it seems unlikely, unless he is Yoda or French.
I mean, in English, it is common to put the adjective in front of the noun,
isn't it?
Class names aren't particularly subject, too strictly, to English
grammar rules. Besides, the coding standards [1] dictate the class
name should be prefixed with the 'parent set' (e.g. extension name),
which in this case is not "Immutable".
[1] https://github.com/php/php-src/blob/master/CODING_STANDARDS#L152
Lazare INEPOLOGLOU
Ingénieur Logiciel
What about putting the new DateTimeImmutable (or whatever it will be called) into a PHP namespace?
Something like \PHP\Foobar\DateTimeImmutable
Is it generally planned to use namespaces for PHP classes? In my opinion it would be nice if the SPL and other classes would be put into such a namespace, too. Are there any plans to do that?
Christian Stoller
-----Original Message-----
From: Peter Cowburn [mailto:petercowburn@gmail.com]
Sent: Friday, December 21, 2012 1:14 AM
To: Lazare Inepologlou
Cc: Larry Garfield; internals@lists.php.net
Subject: Re: [PHP-DEV] DateTime improvement
Of course, I have no idea if anyone in userspace is using
DateTimeImmutable...Well, it seems unlikely, unless he is Yoda or French.
I mean, in English, it is common to put the adjective in front of the noun,
isn't it?
Class names aren't particularly subject, too strictly, to English
grammar rules. Besides, the coding standards [1] dictate the class
name should be prefixed with the 'parent set' (e.g. extension name),
which in this case is not "Immutable".
[1] https://github.com/php/php-src/blob/master/CODING_STANDARDS#L152
Lazare INEPOLOGLOU
Ingénieur Logiciel
I don't think it would be ok to move just DateTimeImmutable to the
namespace.
There were proposal to move all the php functions and classes in
namespaces, so that for example str_replace() could be \Str\replace() and
array_map() could be \Array\map() and so on.
On Fri, 21 Dec 2012 12:33:04 +0400, Christian Stoller stoller@leonex.de
wrote:
What about putting the new DateTimeImmutable (or whatever it will be
called) into a PHP namespace?
Something like \PHP\Foobar\DateTimeImmutableIs it generally planned to use namespaces for PHP classes? In my opinion
it would be nice if the SPL and other classes would be put into such a
namespace, too. Are there any plans to do that?Christian Stoller
-----Original Message-----
From: Peter Cowburn [mailto:petercowburn@gmail.com]
Sent: Friday, December 21, 2012 1:14 AM
To: Lazare Inepologlou
Cc: Larry Garfield; internals@lists.php.net
Subject: Re: [PHP-DEV] DateTime improvementOf course, I have no idea if anyone in userspace is using
DateTimeImmutable...Well, it seems unlikely, unless he is Yoda or French.
I mean, in English, it is common to put the adjective in front of the
noun,
isn't it?Class names aren't particularly subject, too strictly, to English
grammar rules. Besides, the coding standards [1] dictate the class
name should be prefixed with the 'parent set' (e.g. extension name),
which in this case is not "Immutable".[1] https://github.com/php/php-src/blob/master/CODING_STANDARDS#L152
Lazare INEPOLOGLOU
Ingénieur Logiciel
I've seen DateTimeValue used elsewhere for userspace immutable date
time objects. Whether that indicates we SHOULD or SHOULD NOT use that
for an in-C version, I don't know. (I'm inclined to say
should-but-namespace, but I don't know if we're doing that yet.)
http://php.net/manual/en/userlandnaming.rules.php
cheers,
Derick
I have actually started too, but I made it w/o inheritance from DateTime,
and I made many of inline functions to avoid code repetition, so I don't
know how good is it. The code on my work computer, so I can show it
tomorrow.
Derick Rethans derick@php.net писал(а) в своём письме Sun, 16 Dec 2012
16:21:47 +0400:
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.I'm not really against that, but we do need to use the Date namespace -
so DateTimeImmutable. It might be trickier to do than it sounds
though...I've started hacking on this - with some luck I'm done before PHP 5.5
beta1.cheers,
Derick
Hi!
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
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.
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.
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.
Also, there's methods compareTo, createFromTimestamp and createFromDay, it
could be another proposal. I think we are very often create DateTime
objects just from timestamp or year-month-day. So we could introduce this
methods that could not rely on timelib's parsing, and instead just take
numbers directly.
Timestamp doesn't need any timelib parsing AFAIK, but YMD certainly does
- you need to calculate the actual timestamp according to current
timezone, etc.
And I think DateTime lack comparing method. For now I can compare DateTime
objects only by getting their timestamps, but I though that the idea of
DateTime objects can be compared directly, why do you think you can
compare only timestamps?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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.
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.
While this may be a niche to many of you, I've encountered a quite big
amount of people just modifying their DateTime objects with the existing
API and then complaining about their date not being saved to DB.
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...
Marco Pivetta
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.
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?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
People tend to desire API changes that go on the same directions they are
going.
That's nature...
Daniel Ribeiro Gomes Pereira
Twitter https://twitter.com/#!/drgomesp |
Facebookhttps://www.facebook.com/profile.php?id=100000407054469
| LinkedIn http://www.linkedin.com/pub/daniel-ribeiro-gomes/21/414/39
iPhone: +55 (48) 9111-0931
2012/12/11 Stas Malyshev smalyshev@sugarcrm.com
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.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?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
@Stas a DateTime object is the perfect representation of what in DB world
has dozens of different representations. The reasoning behind it is exactly
the same as having a DateTime object vs having a date+time string.
Marco Pivetta
Hi!
@Stas a DateTime object is the perfect representation of what in DB
world has dozens of different representations. The reasoning behind it
is exactly the same as having a DateTime object vs having a date+time
string.
You are confusing internal PHP representation with object identity vs.
value treatment. There's no reason for dates to be treated as non-value
types having complex structure, and if you do not, mutability is not a
question.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Stas Malyshev smalyshev@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.
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