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
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 som
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
On Tue, Mar 26, 2013 at 9:23 AM, Lars Strojny 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 can't be disabl
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 :
> So how do we officially undo something that didn't use an
Am 25.03.2013 um 21:23 schrieb Sebastian Bergmann :
> 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?
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 Mar 6, 2013 4:51 PM, "Nikita Popov" wrote:
> I'd prefer to have nothing over having something bad.
+1
Can we fix this issue, please?
> Nikita
Mike
On Wed, Feb 20, 2013 at 11:21 AM, Gustavo Lopes wrote:
> 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 actu
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/&t
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
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
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
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
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
On Tue, 19 Feb 2013 13:01:18 +0100, Derick Rethans 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 DateTime as bas
>> 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
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."
>
> Th
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
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 wrote:
> Hi!
>
> > a) The DateTimeImmutable class extends the DateTime class. Why was this
> > done this
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 i
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 be
> 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
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
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 DateTime
26 matches
Mail list logo
