Re: [PHP-DEV] Questions regarding DateTimeImmutable
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
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
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
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 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
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 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
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
Re: [PHP-DEV] Questions regarding DateTimeImmutable
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
So how do we officially undo something that didn't use an RFC but should have?
Re: [PHP-DEV] Questions regarding DateTimeImmutable
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
Re: [PHP-DEV] Questions regarding DateTimeImmutable
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 functions that actually accept DateTime: http://code.google.com/**codesearch#search/type=csq=** DateTime%5Cs%5C$%20lang:%**5Ephp$http://code.google.com/codesearch#search/type=csq=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
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
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:phptype=cssq= 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
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 glo...@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:phptype=cs**sq=http://code.google.com/codesearch#search/q=%5C$date-%3Emodify%20lang:phptype=cssq= 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
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:phptype=cssq= 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=csq=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
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 smalys...@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:phptype=cssq=
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=csq=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
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=csq=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
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
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
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
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 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
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 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
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
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
[PHP-DEV] Questions regarding DateTimeImmutable
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
Re: [PHP-DEV] Questions regarding DateTimeImmutable
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
Re: [PHP-DEV] Questions regarding DateTimeImmutable
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
