On Wed, 20 Feb 2013, Gustavo Lopes wrote:
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
--
PHP Internals - PHP Runtime Development Mailing
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
On Wed, 27 Mar 2013, Lester Caine wrote:
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
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.l...@gmail.com:
So how do we officially undo
On Tue, Mar 26, 2013 at 9:23 AM, Lars Strojny l...@strojny.net wrote:
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
On Mar 6, 2013 4:51 PM, Nikita Popov nikita@gmail.com wrote:
I'd prefer to have nothing over having something bad.
+1
Can we fix this issue, please?
Nikita
Mike
On 03/06/2013 10:50 AM, Nikita Popov wrote:
I'd prefer to have nothing over having something bad.
+1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
So how do we officially undo something that didn't use an RFC but should
have?
Am 25.03.2013 um 21:23 schrieb Sebastian Bergmann sebast...@php.net:
On 03/06/2013 10:50 AM, Nikita Popov wrote:
I'd prefer to have nothing over having something bad.
+1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, Feb 20, 2013 at 11:21 AM, Gustavo Lopes glo...@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
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
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
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:
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
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
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:
On Fri, 15 Feb 2013, Nikita Popov wrote:
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
On Fri, 15 Feb 2013, Sanford Whiteman wrote:
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
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
On Tue, 19 Feb 2013 13:01:18 +0100, Derick Rethans der...@php.net wrote:
On Fri, 15 Feb 2013, Sanford Whiteman wrote:
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
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 smalys...@sugarcrm.comwrote:
Hi!
a) The DateTimeImmutable class extends the DateTime class. Why was
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
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
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
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
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
26 matches
Mail list logo
