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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
20 matches
Mail list logo
