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 is
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 ac
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
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
On Thu, Mar 28, 2013 at 12:05 PM, Derick Rethans wrote:
> On Thu, 28 Mar 2013, Lars Strojny wrote:
>
>> Am 27.03.2013 um 21:53 schrieb Derick Rethans :
>>
>> > On Tue, 26 Mar 2013, Michael Wallner wrote:
>> >
>> >> providing DateTimeImmutable as a sibling to DateTime.
>> >
>> > That's fine with me
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 wrote:
> On Thu, 28 Mar 2013, Lars Strojny wrote:
>
> > Am 27.03.2013 um 21
On Thu, 28 Mar 2013, Lars Strojny wrote:
> Am 27.03.2013 um 21:53 schrieb Derick Rethans :
>
> > 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
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
On Thu, 28 Mar 2013 13:04:44 +0400, Lars Strojny wrote:
Hi Derick,
Am 27.03.2013 um 21:53 schrieb Derick Rethans :
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
Hi Derick,
Am 27.03.2013 um 21:53 schrieb Derick Rethans :
> 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 find
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/
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 Wed, Mar 27, 2013 at 2:14 PM, Pierre Joye wrote:
> On Wed, Mar 27, 2013 at 1:49 PM, Andreas Heigl 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 DateTimeImmu
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 potentia
On Wed, Mar 27, 2013 at 1:49 PM, Andreas Heigl 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 o
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
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 i
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 :
> 2013.03.26. 20:29, "Michael Wallner" ezt írta:
>>
>> Hi all!
>>
>> I am concerned by the introduction of DateTimeImmutable extending
>> D
2013.03.26. 20:29, "Michael Wallner" 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 frustra
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 t
20 matches
Mail list logo
