Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Derick Rethans]

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 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Lester Caine]

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Derick Rethans]

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 List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Pierre Joye]

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 disabled and always
used as default date handling.

Cheers,
--
Pierre

@pierrejoye

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Lars Strojny]

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 RFC but should
> have?


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Lars Strojny]

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

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Levi Morrison]

So how do we officially undo something that didn't use an RFC but should
have?

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[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

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Michael Wallner]

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

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Nikita Popov]

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 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.
>

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

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Gustavo Lopes]

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Benjamin Eberlei]

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 wrote:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Stas Malyshev]

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Benjamin Eberlei]

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 wrote:

> 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
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Gustavo Lopes]

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Stas Malyshev]

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Gustavo Lopes]

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 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Levi Morrison]

>> 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.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Derick Rethans]

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 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Derick Rethans]

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 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Benjamin Eberlei]

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 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Stas Malyshev]

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Sebastian Bergmann]

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 BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/   http://thePHP.cc/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Levi Morrison]

> 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.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Sanford Whiteman]

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


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Questions regarding DateTimeImmutable

[Nikita Popov]

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