Hi internals,
for PHP 5.5 a new DateTimeImmutable class was introduced, which is a
variant of DateTime, which has methods working on a clone of the original
object.
There was no RFC on this and some of the design decisions are a bit
uncleared to me, so I figured I'd write a mail:
a) The DateTimeImmutable class extends the DateTime class. Why was this
done this way? Both classes are incompatible (as in the inheritance
violates LSP). E.g. if you hint against DateTime, then passing in
DateTimeImmutable will not work (as the behavior is different). The same
also applies the other way around (DateTime extending DateTimeImmutable).
Imho a mutable and an immutable variant of a class can't reasonably extend
from one another, so I'm not sure why this was done.
b) The DateTimeImmutable class is (method-wise) an exact copy of DateTime.
This makes for some rather weird method names for an immutable object. E.g.
there is DateTimeImmutable::modify, which to me seems quite contradictory.
There are also a lot of methods of the DateTimeImmutable::setTime form,
which also seems rather odd and confusing (how can I set something on an
immutable object?)
The DateTimeImmutable class was added to fix design issues with DateTime,
but the way it was implemented I think it just replaced one evil with
another one. Could we maybe reconsider this?
Nikita
I think it was done to ease adoption even though it was known to
violate LSP. To quote Stas, "As for established practice, everybody
expects DateTime, so IMHO we should leave DateTime as base class even
though it's not strictly OO-pure."
This way does let users sub in DateTimeImmutable more easily and patch
over a ton of unintended -- maybe not even fully noted or understood
-- defects in their apps? I dunno.
I looked at the first discussion from late 2010 after Benjamin E.
sketched out the language addition and Larry G. suggested making them
siblings as opposed to subclassing, but those discussions seemed to
peter out and by the time Derick wrote the patch, the class model was
kind of accepted.
The discussion from 2012 is rather mild considering some pretty
disparate viewpoints are represented, viz. users don't care about
mutability vs. users have been coding as if DT were immutable.
-- Sandy
I think it was done to ease adoption even though it was known to
violate LSP. To quote Stas, "As for established practice, everybody
expects DateTime, so IMHO we should leave DateTime as base class even
though it's not strictly OO-pure."
I can see how easing adoption would be logical, but honestly I don't
think this will help. Just because the outward API looks the same,
a DateTimeImmutable is NOT a drop in replacement for DateTime. I
honestly think that having one or the other inheriting from the other
isn't just an LSP violation: it's a really big one. It's so big I
don't think there's much worth of having them inherit; I dare say it
would hurt it.
This way does let users sub in DateTimeImmutable more easily and patch
over a ton of unintended -- maybe not even fully noted or understood
-- defects in their apps? I dunno.
Exactly.
I think it was done to ease adoption even though it was known to
violate LSP. To quote Stas, "As for established practice, everybody
expects DateTime, so IMHO we should leave DateTime as base class even
though it's not strictly OO-pure."This way does let users sub in DateTimeImmutable more easily and patch
over a ton of unintended -- maybe not even fully noted or understood
-- defects in their apps? I dunno.
Yes, that's exactly the idea.
cheers,
Derick
I think it was done to ease adoption even though it was known to
violate LSP. To quote Stas, "As for established practice, everybody
expects DateTime, so IMHO we should leave DateTime as base class even
though it's not strictly OO-pure."
This is not a matter of some abstract OO-pureness.
The problem with the argument that "everybody 'typehints' DateTime; we
should inherit from it so that the code will run when the pass it a
DateTimeImmutable" is that it assumes that everybody who typehints
DateTime uses DateTime in a manner compatible with DateTimeImmutable. I
don't believe that no one relies on DateTime method's side effects -- I
certainly do.
This way does let users sub in DateTimeImmutable more easily and patch
over a ton of unintended -- maybe not even fully noted or understood
-- defects in their apps? I dunno.
The argument is that people are using DateTime as if it were immutable and
you can now fix this wrong code by passing a DateTimeImmutable instead? I
find it highly unlikely.
Yes, that's exactly the idea.
IMO, the classes should not be part of the same hierarchy. If it doesn't
matter whether a DateTime or a DateTimeImmutable is passed, then don't
typehint. An advantage of PHP is that you can use duck typing. If you do
typehint, but then the subclasses break the post-conditions... what's the
point?
Even if most people DO use DateTime in a compatible way, this is a very
myopic way to advance the language or handle a transition. If the
DateTimeImmutable interface is superior, people will move to it. If it's
important for functions to accept both (I don't think it is), a common
superclass with weaker guarantees can be extracted.
--
Gustavo Lopes
Hi!
The problem with the argument that "everybody 'typehints' DateTime; we
should inherit from it so that the code will run when the pass it a
DateTimeImmutable" is that it assumes that everybody who typehints
DateTime uses DateTime in a manner compatible with DateTimeImmutable. I
don't believe that no one relies on DateTime method's side effects -- I
certainly do.
We can not make sense of the problem if we keep talking in terms of
"everybody is doing this or that". There's nothing that "everybody" is
doing - there are tons of different usage patterns, some of them common,
some incompatible. We need to look on what is more probable - that
people use DateTime as hint for operations that do not modify the
incoming object or that they do modify it and also would put
DateTimeImmutable in this code.
So on one side we have existing code that would not accept
DateTimeImmutable without extensive modification, unless we create the
inheritance, on the other side we have some code that modifies DateTime
and should be protected from passing DateTimeImmutable - but there's no
such code yet since nobody passes DateTimeImmutable anywhere yet, so we
don't make any problem for existing code.
My personal opinion is that having the first covered covers more cases
than the second, since it saves more boilerplate code.
The argument is that people are using DateTime as if it were immutable and
you can now fix this wrong code by passing a DateTimeImmutable instead? I
find it highly unlikely.
I find it highly likely that majoirty of DateTime users don't care if
it's mutable or not since they either don't change it (most frequent use
case) or use something like $foo = $bar->modify("+1 day"); and never
rely on the fact that $bar was modified. Of course, I have no data about
how many but I find it highly likely that many users simply don't care
about the difference.
IMO, the classes should not be part of the same hierarchy. If it doesn't
This means hinting for DateTime would be useless for common
(non-modifying) use cases and there's no recourse to do anything else
since there's no common ground. The name DateTimeImmutable kind of
implies it is the same as DateTime only not mutable, but in fact writing
code that could accept them both
Even if most people DO use DateTime in a compatible way, this is a very
myopic way to advance the language or handle a transition. If the
DateTimeImmutable interface is superior, people will move to it. If it's
important for functions to accept both (I don't think it is), a common
superclass with weaker guarantees can be extracted.
That would create javaesque constructs of classes and interfaces that do
nothing useful but exist merely so that there would be nice hierarchies,
and people would have to learn all that to use them, which makes it
significantly harder to use the language.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Em 2013-02-20 9:41, Stas Malyshev escreveu:
There's nothing that "everybody" is
doing - there are tons of different usage patterns, some of them
common,
some incompatible. We need to look on what is more probable - that
people use DateTime as hint for operations that do not modify the
incoming object or that they do modify it and also would put
DateTimeImmutable in this code.
No, we do not need to look on what is more probable. It's only when we
select this very ill-advised option, that we need to start guessing if
people used all the guarantees of DateTime (namely its side-effects) or
not.
So on one side we have existing code that would not accept
DateTimeImmutable without extensive modification,
To "accept a DateTimeImmutable" is not the same as "no recoverable
fatal error when a DateTimeImmutable is passed". You can't possibly know
whether passing a DateTimeImmutable is safe without reviewing the code
on all the call hierarchy starting from where your DateTimeImmutable is
passed.
unless we create the
inheritance, on the other side we have some code that modifies
DateTime
and should be protected from passing DateTimeImmutable - but there's
no
such code yet since nobody passes DateTimeImmutable anywhere yet, so
we
don't make any problem for existing code.
"[C]ode that modifies DateTime and should be protected from passing
DateTimeImmutable" DOES exist already. Saying that it's not a problem
for existing code because no one passes DateTimeImmutable is a
misleading statement -- it assumes codebases exist in isolation. But
current libraries that take DateTime will still be used in 5.5; in fact,
that's the basis of your whole argument for this choice.
I find it highly likely that majoirty of DateTime users don't care if
it's mutable or not since they either don't change it (most frequent
use
case) or use something like $foo = $bar->modify("+1 day"); and never
rely on the fact that $bar was modified. Of course, I have no data
about
how many but I find it highly likely that many users simply don't
care
about the difference.
Here is some data:
http://code.google.com/codesearch#search/&q=%5C$date-%3Emodify%20lang:php&type=cs&sq=
As you can see, your assumption is false. In the majority of cases,
there is no assignment.
--
Gustavo Lopes
The problem with DateTimeImmutable extends DateTime is, that the client
code not just magically works with immutable date times, it also works
differently with regard to state, so this will be a source of subtle and
annoying bugs. See the following example:
https://gist.github.com/beberlei/4994193
The client code actually has to know if the instance is DateTime or
DateTimeImmutable and behave differently. Or just use "clone" as before,
and then there is no difference to pre 5.5 code anyways.
On Wed, Feb 20, 2013 at 10:07 AM, Gustavo Lopes glopes@nebm.ist.utl.ptwrote:
Em 2013-02-20 9:41, Stas Malyshev escreveu:
There's nothing that "everybody" is
doing - there are tons of different usage patterns, some of them common,
some incompatible. We need to look on what is more probable - that
people use DateTime as hint for operations that do not modify the
incoming object or that they do modify it and also would put
DateTimeImmutable in this code.No, we do not need to look on what is more probable. It's only when we
select this very ill-advised option, that we need to start guessing if
people used all the guarantees of DateTime (namely its side-effects) or not.So on one side we have existing code that would not accept
DateTimeImmutable without extensive modification,
To "accept a DateTimeImmutable" is not the same as "no recoverable fatal
error when a DateTimeImmutable is passed". You can't possibly know whether
passing a DateTimeImmutable is safe without reviewing the code on all the
call hierarchy starting from where your DateTimeImmutable is passed.unless we create the
inheritance, on the other side we have some code that modifies DateTime
and should be protected from passing DateTimeImmutable - but there's no
such code yet since nobody passes DateTimeImmutable anywhere yet, so we
don't make any problem for existing code."[C]ode that modifies DateTime and should be protected from passing
DateTimeImmutable" DOES exist already. Saying that it's not a problem for
existing code because no one passes DateTimeImmutable is a misleading
statement -- it assumes codebases exist in isolation. But current libraries
that take DateTime will still be used in 5.5; in fact, that's the basis of
your whole argument for this choice.I find it highly likely that majoirty of DateTime users don't care if
it's mutable or not since they either don't change it (most frequent use
case) or use something like $foo = $bar->modify("+1 day"); and never
rely on the fact that $bar was modified. Of course, I have no data about
how many but I find it highly likely that many users simply don't care
about the difference.Here is some data:
http://code.google.com/codesearch#search/&q=%5C$date-
%3Emodify%20lang:php&type=cs&**sq=http://code.google.com/codesearch#search/&q=%5C$date-%3Emodify%20lang:php&type=cs&sq=As you can see, your assumption is false. In the majority of cases, there
is no assignment.--
Gustavo Lopes
Hi!
To "accept a DateTimeImmutable" is not the same as "no recoverable
fatal error when a DateTimeImmutable is passed". You can't possibly know
whether passing a DateTimeImmutable is safe without reviewing the code
on all the call hierarchy starting from where your DateTimeImmutable is
passed.
If I know what the code does with dates, I don't need to review it.
misleading statement -- it assumes codebases exist in isolation. But
current libraries that take DateTime will still be used in 5.5; in fact,
that's the basis of your whole argument for this choice.
This is true. That's why I want to see what is more probable - that
library accepts DateTime and would be fine with DateTimeImmutable or
that library accepts DateTime and would have to be rewritten to work
with DateTimeImmutable.
Here is some data:
http://code.google.com/codesearch#search/&q=%5C$date-%3Emodify%20lang:php&type=cs&sq=
As you can see, your assumption is false. In the majority of cases,
there is no assignment.
This isn't really a good data since most of this code creates its own
DateTime and thus there's very little relevancy to what we're talking
about. If you look up the functions that actually accept DateTime:
http://code.google.com/codesearch#search/&type=cs&q=DateTime%5Cs%5C$%20lang:%5Ephp$
the picture would be quite different. I scanned through first 5 pages
and couldn't find a function that actually calls modify() on DateTime
object it receives.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
People are not using modify() in this way, because they have been bitten
before I would suppose.
What i find important about the DateTime vs DateTimeImmutable is the
expectations I have with regard to how they work with internal state.
If i have a typehint for DateTime, i clone the object before working on it.
If I have a typehint for DateTimeImmutable, i just start using it.
This means the usage patterns for both objects will look very different.
Also for example, the following code is not possible without instanceof
checks:
function thirtyDaysLater(DateTime $dt)
{
$later = clone $dt;
$later->modify("+30 day");
return $later;
}
If i pass a DateTimeImmutable in there, the code will not work.
Imho its not about people are not using it this way in open source code,
its about creating a very likely source of bugs of the ugly to debug kind.
On Wed, Feb 20, 2013 at 10:32 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
To "accept a DateTimeImmutable" is not the same as "no recoverable
fatal error when a DateTimeImmutable is passed". You can't possibly know
whether passing a DateTimeImmutable is safe without reviewing the code
on all the call hierarchy starting from where your DateTimeImmutable is
passed.If I know what the code does with dates, I don't need to review it.
misleading statement -- it assumes codebases exist in isolation. But
current libraries that take DateTime will still be used in 5.5; in fact,
that's the basis of your whole argument for this choice.This is true. That's why I want to see what is more probable - that
library accepts DateTime and would be fine with DateTimeImmutable or
that library accepts DateTime and would have to be rewritten to work
with DateTimeImmutable.Here is some data:
http://code.google.com/codesearch#search/&q=%5C$date-%3Emodify%20lang:php&type=cs&sq=
As you can see, your assumption is false. In the majority of cases,
there is no assignment.This isn't really a good data since most of this code creates its own
DateTime and thus there's very little relevancy to what we're talking
about. If you look up the functions that actually accept DateTime:http://code.google.com/codesearch#search/&type=cs&q=DateTime%5Cs%5C$%20lang:%5Ephp$
the picture would be quite different. I scanned through first 5 pages
and couldn't find a function that actually calls modify() on DateTime
object it receives.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Em 2013-02-20 10:32, Stas Malyshev escreveu:
This isn't really a good data since most of this code creates its own
DateTime and thus there's very little relevancy to what we're talking
about. If you look up the functions that actually accept DateTime:http://code.google.com/codesearch#search/&type=cs&q=DateTime%5Cs%5C$%20lang:%5Ephp$
the picture would be quite different. I scanned through first 5 pages
and couldn't find a function that actually calls modify() on DateTime
object it receives.
Well, the majority of the code here just calls ->format() (which may
very well be considered a point in your favor). But again most of the
time an operation with side effects is called, there's no assignment. I
also went through the first pages and saw one instance of an operation
with side effects with assignment and three others without (setTime,
setTimestamp and setTimeZone).
It's very tedious to go through this because most that don't just call
format just set a field with it. This is potentially dangerous, of
course, depending on what's further done with the field.
In any case, this seems like a pointless exercise. The solution is
simple: separate the classes and provide a toDateTime() on
DateTimeImmutable for interoperability purposes. One wouldn't need to go
through Atom libraries code to know this is a solution that can't cause
problems.
--
Gustavo Lopes
On Wed, Feb 20, 2013 at 11:21 AM, Gustavo Lopes glopes@nebm.ist.utl.ptwrote:
Em 2013-02-20 10:32, Stas Malyshev escreveu:
This isn't really a good data since most of this code creates its own
DateTime and thus there's very little relevancy to what we're talking
about. If you look up the functions that actually accept DateTime:http://code.google.com/codesearch#search/&type=cs&q=
DateTime%5Cs%5C$%20lang:%**5Ephp$http://code.google.com/codesearch#search/&type=cs&q=DateTime%5Cs%5C$%20lang:%5Ephp$the picture would be quite different. I scanned through first 5 pages
and couldn't find a function that actually calls modify() on DateTime
object it receives.Well, the majority of the code here just calls ->format() (which may very
well be considered a point in your favor). But again most of the time an
operation with side effects is called, there's no assignment. I also went
through the first pages and saw one instance of an operation with side
effects with assignment and three others without (setTime, setTimestamp and
setTimeZone).It's very tedious to go through this because most that don't just call
format just set a field with it. This is potentially dangerous, of course,
depending on what's further done with the field.In any case, this seems like a pointless exercise. The solution is simple:
separate the classes and provide a toDateTime() on DateTimeImmutable for
interoperability purposes. One wouldn't need to go through Atom libraries
code to know this is a solution that can't cause problems.
This seems like a reasonable suggestion.
If no such compromise can be reached, then I would suggest that the
DateTimeImmutable addition be reverted altogether. Looking over the thread
it seems that most people agree on the design flaws and those who don't are
more or less indifferent about DateTimeImmutable either way (e.g. Stas).
I'd prefer to have nothing over having something bad.
Nikita
I'd prefer to have nothing over having something bad.
+1
Can we fix this issue, please?
Nikita
Mike
I'd prefer to have nothing over having something bad.
+1
Am 25.03.2013 um 21:23 schrieb Sebastian Bergmann sebastian@php.net:
I'd prefer to have nothing over having something bad.
+1
So how do we officially undo something that didn't use an RFC but should
have?
Start simple: ask Derick to revert and go through the usual RFC process.
@Derick: given the overall response on the list, could you revert the introduction of DateTimeImmutable?
cu,
Lars
Am 26.03.2013 um 01:21 schrieb Levi Morrison morrison.levi@gmail.com:
So how do we officially undo something that didn't use an RFC but should
have?
Start simple: ask Derick to revert and go through the usual RFC process.
@Derick: given the overall response on the list, could you revert the introduction of DateTimeImmutable?
huge +1. Even more for an extension that can't be disabled and always
used as default date handling.
Cheers,
Pierre
@pierrejoye
The solution is simple: separate the classes and provide a
toDateTime() on DateTimeImmutable for interoperability purposes.
Do you have time to make a patch? I unfortunately don't.
cheers,
Derick
Am 15.02.2013 21:49, schrieb Nikita Popov:
a) The DateTimeImmutable class extends the DateTime class. Why was this
done this way? Both classes are incompatible (as in the inheritance
violates LSP). E.g. if you hint against DateTime, then passing in
DateTimeImmutable will not work (as the behavior is different). The same
also applies the other way around (DateTime extending DateTimeImmutable).
Imho a mutable and an immutable variant of a class can't reasonably extend
from one another, so I'm not sure why this was done.
I raised the same question to Derick and he said that it had to be done
this way because of BC issues. The way it is implemented right now makes
no sense to me at all. Thank you, Nikita, for bringing this to the
attention of this list.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Hi!
a) The DateTimeImmutable class extends the DateTime class. Why was this
done this way? Both classes are incompatible (as in the inheritance
They're not really "incompatible". Functions that do not modify dates
would work just fine. So it's "not 100% compatible", which is not the
same as incompatible. Of course, we could instead create
DateTimeBaseAbstractClass, but IMHO rewriting all your code to support
it wouldn't be worth the trouble for 99.9% of the code, so what would
end up happening that nobody could use DateTimeImmutable with any
existing code that expects DateTime. I personally don't see much point
in DateTimeImmutable anyway (immutable data structures are very
important for concurrent programs but for PHP I don't see much benefit)
but if people need it, fine. But ask yourself a question - do you really
want to rewrite every library that accepts DateTime as an argument in
order to use DateTimeImmutable?
b) The DateTimeImmutable class is (method-wise) an exact copy of DateTime.
This makes for some rather weird method names for an immutable object. E.g.
there is DateTimeImmutable::modify, which to me seems quite contradictory.
There are also a lot of methods of the DateTimeImmutable::setTime form,
which also seems rather odd and confusing (how can I set something on an
immutable object?)
I don't see how it's so hard to grasp - it sets time and returns the
modified object. I can't believe you genuinely don't understand how it
works. I have a feeling this "confusing" argument in getting somewhat
stale: PHP users - especially those that want to use specially designed
classes that are useable only in context of design of non-trivial
complexity - have sufficient brain capacity to understand what setTime
could do. And if they absolutely can't, they can to the unthinkable -
read the manual.
So I can see the LSP argument - but "confusing" argument really doesn't
seem to apply here.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hey,
would it be possible for DateTime and DateTimeImmutable to not extend each
other at all and be two seperate classes?
greetings,
Benjamin
On Sun, Feb 17, 2013 at 12:30 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
a) The DateTimeImmutable class extends the DateTime class. Why was this
done this way? Both classes are incompatible (as in the inheritanceThey're not really "incompatible". Functions that do not modify dates
would work just fine. So it's "not 100% compatible", which is not the
same as incompatible. Of course, we could instead create
DateTimeBaseAbstractClass, but IMHO rewriting all your code to support
it wouldn't be worth the trouble for 99.9% of the code, so what would
end up happening that nobody could use DateTimeImmutable with any
existing code that expects DateTime. I personally don't see much point
in DateTimeImmutable anyway (immutable data structures are very
important for concurrent programs but for PHP I don't see much benefit)
but if people need it, fine. But ask yourself a question - do you really
want to rewrite every library that accepts DateTime as an argument in
order to use DateTimeImmutable?b) The DateTimeImmutable class is (method-wise) an exact copy of
DateTime.
This makes for some rather weird method names for an immutable object.
E.g.
there is DateTimeImmutable::modify, which to me seems quite
contradictory.
There are also a lot of methods of the DateTimeImmutable::setTime form,
which also seems rather odd and confusing (how can I set something on an
immutable object?)I don't see how it's so hard to grasp - it sets time and returns the
modified object. I can't believe you genuinely don't understand how it
works. I have a feeling this "confusing" argument in getting somewhat
stale: PHP users - especially those that want to use specially designed
classes that are useable only in context of design of non-trivial
complexity - have sufficient brain capacity to understand what setTime
could do. And if they absolutely can't, they can to the unthinkable -
read the manual.
So I can see the LSP argument - but "confusing" argument really doesn't
seem to apply here.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
for PHP 5.5 a new DateTimeImmutable class was introduced, which is a
variant of DateTime, which has methods working on a clone of the
original object.There was no RFC on this and some of the design decisions are a bit
uncleared to me, so I figured I'd write a mail:a) The DateTimeImmutable class extends the DateTime class. Why was
this done this way? Both classes are incompatible (as in the
inheritance violates LSP). E.g. if you hint against DateTime, then
passing in DateTimeImmutable will not work (as the behavior is
different). The same also applies the other way around (DateTime
extending DateTimeImmutable). Imho a mutable and an immutable variant
of a class can't reasonably extend from one another, so I'm not sure
why this was done.
It was mostly done so that methods and code accepting do not need
signature changes. In many cases library code would accept a DateTime,
call modify and return the changed object - not realizing that the
original object was changed as well causes issues with calling code. By
having DateTimeImmutable extend DateTime they can continue to pass them
in, without having to change library code at all.
b) The DateTimeImmutable class is (method-wise) an exact copy of
DateTime. This makes for some rather weird method names for an
immutable object. E.g. there is DateTimeImmutable::modify, which to me
seems quite contradictory. There are also a lot of methods of the
DateTimeImmutable::setTime form, which also seems rather odd and
confusing (how can I set something on an immutable object?)
It just returns the changed object instead of changing the object itself
and returning the changed object (as DateTime does).
cheers,
Derick
a) The DateTimeImmutable class extends the DateTime class. Why was
this done this way? Both classes are incompatible (as in the
inheritance violates LSP). E.g. if you hint against DateTime, then
passing in DateTimeImmutable will not work (as the behavior is
different). The same also applies the other way around (DateTime
extending DateTimeImmutable). Imho a mutable and an immutable variant
of a class can't reasonably extend from one another, so I'm not sure
why this was done.It was mostly done so that methods and code accepting do not need
signature changes. In many cases library code would accept a DateTime,
call modify and return the changed object - not realizing that the
original object was changed as well causes issues with calling code. By
having DateTimeImmutable extend DateTime they can continue to pass them
in, without having to change library code at all.
What if they return the same object knowing that modify actually
modifies the object? I personally would have done that except in the
lucky situation that I used it in the return statement:
return $timestamp->modify('+30 days');
Then I'd luckily work with DateTimeImmutable.
While I personally think DateTime should have been immutable from the
beginning, I don't think it's in PHP's best interest to try to fix
this particular problem by introducing DateTimeImmutable.
Levi Morrison wrote:
While I personally think DateTime should have been immutable from the
beginning, I don't think it's in PHP's best interest to try to fix
this particular problem by introducing DateTimeImmutable.
There seems to be some strange assumption that a DateTime value is fixed in some
way? There have been various statements about 'should have been immutable from
the beginning', and while I can see that some uses of it are read only, much of
my own use is in building calendar arrays where one is adding months, days or
hours to select the next set of matches. If this should always have been
'immutable' then how would one handle all the situations where one does need to
update the value?
Now there has been discussions about setters and getters and read only, so
surely this is just another example of something were flagging a variable as
read only would be useful rather than programming in yet another special case?
--
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
Levi Morrison wrote:
While I personally think DateTime should have been immutable from the
beginning, I don't think it's in PHP's best interest to try to fix
this particular problem by introducing DateTimeImmutable.There seems to be some strange assumption that a DateTime value is fixed in
some way? There have been various statements about 'should have been immutable
from the beginning', and while I can see that some uses of it are read only,
much of my own use is in building calendar arrays where one is adding months,
days or hours to select the next set of matches. If this should always have
been 'immutable' then how would one handle all the situations where one does
need to update the value?
The updated value is still returned, it's just that the original object
you call (f.e.) ->modify() on is not.
cheers,
Derick