Re: [PHP-DEV] DateTimeImmutable::modify() return type: doc or language bug?
On Tue, Jan 3, 2023, at 3:48 AM, Philip Hofstetter wrote: > Hi, > > `DateTimeImmutable::modify()` is documented as returning > `DateTimeImmutable`, but it seems to actually be more specifically > returning `static`: > > https://3v4l.org/j9ZSo > > Now I'm wondering whether this is a documentation issue (where it > should return `static|false` and has not been updated to account for > that return type's availability yet) or whether this is a language > issue and the method is supposed to be returning `DateTimeImmutable` > instead, though that's probably a considerable BC break. > > If you agree that it's a doc bug, I'll submit a PR. > > Regards, > > Philip That sounds like a doc bug to me. It's likely the doc page hasn't been updated since before the `static` return was added. The code looks like it's doing the right thing. Doc PR, please and thank you! --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] DateTimeImmutable::modify() return type: doc or language bug?
Hi, `DateTimeImmutable::modify()` is documented as returning `DateTimeImmutable`, but it seems to actually be more specifically returning `static`: https://3v4l.org/j9ZSo Now I'm wondering whether this is a documentation issue (where it should return `static|false` and has not been updated to account for that return type's availability yet) or whether this is a language issue and the method is supposed to be returning `DateTimeImmutable` instead, though that's probably a considerable BC break. If you agree that it's a doc bug, I'll submit a PR. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeImmutable
On Wed, 27 Mar 2013, Jordi Boggiano wrote:
On 27.03.2013 13:18, Lars Strojny wrote:
Not really, as an interface guarantees behavior, which is not
possible for DateTimeImmutable and DateTime.
The interface could be a subset of DateTime public methods, including
only the readonly ones.
I can't imagine how this could possibly be named in a sane way though :/
Name aside, an interface is sort of very useful otherwise we're ending
up with code like this all over the time:
first_arg_ce = zend_get_class_entry(start);
if ((first_arg_ce != date_ce_date) (first_arg_ce !=
date_ce_immutable)) {
And that's a real pain, so an interface for just the gettings (and other
methods not modifying/changing anything is probably a good idea. I'll
see if I can work on this over the Easter weekend.
cheers,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeImmutable
Hi Derick, Am 27.03.2013 um 21:53 schrieb Derick Rethans der...@php.net: On Tue, 26 Mar 2013, Michael Wallner wrote: providing DateTimeImmutable as a sibling to DateTime. That's fine with me, but I am not having the time to work on a patch right now. Happens. Let’s revert it till somebody finds some time to do it. Could you revert it? cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeImmutable
On Thu, 28 Mar 2013 13:04:44 +0400, Lars Strojny l...@strojny.net wrote: Hi Derick, Am 27.03.2013 um 21:53 schrieb Derick Rethans der...@php.net: On Tue, 26 Mar 2013, Michael Wallner wrote: providing DateTimeImmutable as a sibling to DateTime. That's fine with me, but I am not having the time to work on a patch right now. Happens. Let’s revert it till somebody finds some time to do it. Could you revert it? cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hi, Sorry, maybe I missed something, but what the consensus did we achieve here? Make an interface? Or maybe make an abstract class with constructor, late static binded fabric methods (which btw could solve problems with making custom datetime class in userland), and some of the methods like diff and so on? Or maybe something else? PS I think I can make a patch on these weekends. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeImmutable
Nikita Nefedov wrote: Sorry, maybe I missed something, but what the consensus did we achieve here? Make an interface? Or maybe make an abstract class with constructor, late static binded fabric methods (which btw could solve problems with making custom datetime class in userland), and some of the methods like diff and so on? Or maybe something else? I think that the general consensus is that this needs to have a proper RFC generated and all the ramifications investigated properly? It's not the '5 minute fix' that was originally thought. When DateTime was first added it caused a lot of problems simply because there were/are other library elements doing the same job and clashing. This is perhaps an area where the original design was the problem since many people seem to think that it was wrong, so 'correcting' it needs proper consideration? -- 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] DateTimeImmutable
On Thu, 28 Mar 2013, Lars Strojny wrote: Am 27.03.2013 um 21:53 schrieb Derick Rethans der...@php.net: On Tue, 26 Mar 2013, Michael Wallner wrote: providing DateTimeImmutable as a sibling to DateTime. That's fine with me, but I am not having the time to work on a patch right now. Happens. Let’s revert it till somebody finds some time to do it. Could you revert it? No, let's not revert it. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeImmutable
I'm on my easter holidays and I have some spare time to revert the changes introduced by the DateTimeImmutable for you Derick. Please let me know if you want me to do it. On Thu, Mar 28, 2013 at 12:05 PM, Derick Rethans der...@php.net wrote: On Thu, 28 Mar 2013, Lars Strojny wrote: Am 27.03.2013 um 21:53 schrieb Derick Rethans der...@php.net: On Tue, 26 Mar 2013, Michael Wallner wrote: providing DateTimeImmutable as a sibling to DateTime. That's fine with me, but I am not having the time to work on a patch right now. Happens. Let’s revert it till somebody finds some time to do it. Could you revert it? No, let's not revert it. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeImmutable
On Thu, Mar 28, 2013 at 12:05 PM, Derick Rethans der...@php.net wrote: On Thu, 28 Mar 2013, Lars Strojny wrote: Am 27.03.2013 um 21:53 schrieb Derick Rethans der...@php.net: On Tue, 26 Mar 2013, Michael Wallner wrote: providing DateTimeImmutable as a sibling to DateTime. That's fine with me, but I am not having the time to work on a patch right now. Happens. Let’s revert it till somebody finds some time to do it. Could you revert it? No, let's not revert it. I'd rather revert until a consensus is reached. Having a sub optimal solution, at best, only because one or more developers did not get the time to sit down on it is not going to be a good way to get new features in php. Can't make it for 5.5? 5.6 is in around a year, we lived years without this, we can wait one more year. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeImmutable
On Thu, 28 Mar 2013, Santiago Lizardo wrote: I'm on my easter holidays and I have some spare time to revert the changes introduced by the DateTimeImmutable for you Derick. Please let me know if you want me to do it. No, don't revert it. It needs to be a sibling class to DateTime instead of inherited like it is now. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeImmutable
2013.03.26. 20:29, Michael Wallner m...@php.net ezt írta: Hi all! I am concerned by the introduction of DateTimeImmutable extending DateTime, and despite not being the talking guy, I'll try to outline the reasons why I and obviously a lot of other people think so. I can understand the frustration with a DateTime that should not have been modifiable in the first place and the wish to improve upon things and to lead users to the proper way. But, this is not the right way. If interoperability was in mind, it will not be given, because every single API which has been written in the last seven years and has DateTime in it's signature is potentially broken. The code may and should be able to expect a modifiable instance of DateTime, which is no longer guaranteed. The argument, that it was implemented this way, so that method signatures do not have to be changed, is weak, because every method has to be reviewed, and a method signature change would actually be the right thing to accept a DateTimeImmutable, because it does not act like a DateTime. It will lead to lots of boilerplate typechecking code with instanceof because it actually is not the same type. DateTimeImmutable extending DateTime will instantly create BC issues, which we will suffer from a long time. The toughtful developer, which already cloned the DateTimes in his methods won't benefit either, because now he's cloning DateTimeImmutables. In my opinion, the only way to solve this issue is through documentation, advocation, publication and providing DateTimeImmutable as a sibling to DateTime. DateTime is here, and we cannot go back in time, but we might deprecate DateTime* and introduce a date namespace in PHP-next to clean up this front, but this already goes beyond the issue with DateTimeImmutable. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php would it make sense to introduce an interface wich both DateTime and DateTimeImmutable implements? that way you can typehint for both if you know that both classes are fine for you.
Re: [PHP-DEV] DateTimeImmutable
Not really, as an interface guarantees behavior, which is not possible for DateTimeImmutable and DateTime. Am 27.03.2013 um 09:03 schrieb Ferenc Kovacs tyr...@gmail.com: 2013.03.26. 20:29, Michael Wallner m...@php.net ezt írta: Hi all! I am concerned by the introduction of DateTimeImmutable extending DateTime, and despite not being the talking guy, I'll try to outline the reasons why I and obviously a lot of other people think so. I can understand the frustration with a DateTime that should not have been modifiable in the first place and the wish to improve upon things and to lead users to the proper way. But, this is not the right way. If interoperability was in mind, it will not be given, because every single API which has been written in the last seven years and has DateTime in it's signature is potentially broken. The code may and should be able to expect a modifiable instance of DateTime, which is no longer guaranteed. The argument, that it was implemented this way, so that method signatures do not have to be changed, is weak, because every method has to be reviewed, and a method signature change would actually be the right thing to accept a DateTimeImmutable, because it does not act like a DateTime. It will lead to lots of boilerplate typechecking code with instanceof because it actually is not the same type. DateTimeImmutable extending DateTime will instantly create BC issues, which we will suffer from a long time. The toughtful developer, which already cloned the DateTimes in his methods won't benefit either, because now he's cloning DateTimeImmutables. In my opinion, the only way to solve this issue is through documentation, advocation, publication and providing DateTimeImmutable as a sibling to DateTime. DateTime is here, and we cannot go back in time, but we might deprecate DateTime* and introduce a date namespace in PHP-next to clean up this front, but this already goes beyond the issue with DateTimeImmutable. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php would it make sense to introduce an interface wich both DateTime and DateTimeImmutable implements? that way you can typehint for both if you know that both classes are fine for you. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeImmutable
On 27.03.2013 13:18, Lars Strojny wrote: Not really, as an interface guarantees behavior, which is not possible for DateTimeImmutable and DateTime. The interface could be a subset of DateTime public methods, including only the readonly ones. I can't imagine how this could possibly be named in a sane way though :/ Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeImmutable
Am 27.03.13 13:41, schrieb Jordi Boggiano: On 27.03.2013 13:18, Lars Strojny wrote: Not really, as an interface guarantees behavior, which is not possible for DateTimeImmutable and DateTime. The interface could be a subset of DateTime public methods, including only the readonly ones. I can't imagine how this could possibly be named in a sane way though :/ DateTimeInterface or DateTimeROInterface? Cheers Cheers -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5 E 08°23'58 | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ smime.p7s Description: S/MIME Kryptografische Unterschrift
Re: [PHP-DEV] DateTimeImmutable
On Wed, Mar 27, 2013 at 1:49 PM, Andreas Heigl andr...@heigl.org wrote: Am 27.03.13 13:41, schrieb Jordi Boggiano: On 27.03.2013 13:18, Lars Strojny wrote: Not really, as an interface guarantees behavior, which is not possible for DateTimeImmutable and DateTime. The interface could be a subset of DateTime public methods, including only the readonly ones. I can't imagine how this could possibly be named in a sane way though :/ DateTimeInterface or DateTimeROInterface? I'd to re post Lars suggestion from another thread. Do a RFC. This is going again in all possible directions and I fear that we will not get a good solution at the end of the day. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeImmutable
On 3/26/13 3:29 PM, Michael Wallner wrote: I am concerned by the introduction of DateTimeImmutable extending DateTime ... If interoperability was in mind, it will not be given, because every single API which has been written in the last seven years and has DateTime in it's signature is potentially broken. The code may and should be able to expect a modifiable instance of DateTime, which is no longer guaranteed. ... In my opinion, the only way to solve this issue is through documentation, advocation, publication and providing DateTimeImmutable as a sibling to DateTime. Much agreed. DateTimeImmutable is welcomed as a better design, but it is not a clean substitute for a DataTime object. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeImmutable
On Wed, Mar 27, 2013 at 2:14 PM, Pierre Joye pierre@gmail.com wrote: On Wed, Mar 27, 2013 at 1:49 PM, Andreas Heigl andr...@heigl.org wrote: Am 27.03.13 13:41, schrieb Jordi Boggiano: On 27.03.2013 13:18, Lars Strojny wrote: Not really, as an interface guarantees behavior, which is not possible for DateTimeImmutable and DateTime. The interface could be a subset of DateTime public methods, including only the readonly ones. I can't imagine how this could possibly be named in a sane way though :/ DateTimeInterface or DateTimeROInterface? I'd to re post Lars suggestion from another thread. Do a RFC. This is going again in all possible directions and I fear that we will not get a good solution at the end of the day. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php agree, but the current implementation shouldn't be shipped until we find an acceptable solution. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] DateTimeImmutable
On Wed, 2013-03-27 at 17:10 +0100, Ferenc Kovacs wrote: agree, but the current implementation shouldn't be shipped until we find an acceptable solution. +1 johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeImmutable
On Tue, 26 Mar 2013, Michael Wallner wrote: providing DateTimeImmutable as a sibling to DateTime. That's fine with me, but I am not having the time to work on a patch right now. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] DateTimeImmutable
Hi all! I am concerned by the introduction of DateTimeImmutable extending DateTime, and despite not being the talking guy, I'll try to outline the reasons why I and obviously a lot of other people think so. I can understand the frustration with a DateTime that should not have been modifiable in the first place and the wish to improve upon things and to lead users to the proper way. But, this is not the right way. If interoperability was in mind, it will not be given, because every single API which has been written in the last seven years and has DateTime in it's signature is potentially broken. The code may and should be able to expect a modifiable instance of DateTime, which is no longer guaranteed. The argument, that it was implemented this way, so that method signatures do not have to be changed, is weak, because every method has to be reviewed, and a method signature change would actually be the right thing to accept a DateTimeImmutable, because it does not act like a DateTime. It will lead to lots of boilerplate typechecking code with instanceof because it actually is not the same type. DateTimeImmutable extending DateTime will instantly create BC issues, which we will suffer from a long time. The toughtful developer, which already cloned the DateTimes in his methods won't benefit either, because now he's cloning DateTimeImmutables. In my opinion, the only way to solve this issue is through documentation, advocation, publication and providing DateTimeImmutable as a sibling to DateTime. DateTime is here, and we cannot go back in time, but we might deprecate DateTime* and introduce a date namespace in PHP-next to clean up this front, but this already goes beyond the issue with DateTimeImmutable. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
