Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119226
MIME-Version: 1.0
References: <CAGKNXQGOjS_--5-XcXyShufisWVnvxaxy-P+_hjsU8iVHWKKwQ@mail.gmail.com>
 <42306d40-5e47-b571-5898-6d7739302ab3@gmx.de>
In-Reply-To: <42306d40-5e47-b571-5898-6d7739302ab3@gmx.de>
Date: Tue, 3 Jan 2023 19:08:01 +0200
Message-ID: <CAAwdEzDsMeromCB=4PO05DSg7cYG_eVHvzjyYKyjKKur2pb2QQ@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: Philip Hofstetter <phofstetter@sensational.ch>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000006c5f305f15f1d4b"
Subject: Re: [PHP-DEV] Re: DateTimeImmutable::modify() return type: doc or
 language bug?
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--00000000000006c5f305f15f1d4b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 3, 2023, 17:44 Christoph M. Becker <cmbecker69@gmx.de> wrote:

> On 03.01.2023 at 10:48, Philip Hofstetter wrote:
>
> > `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.
>
> It is not recommendable to extend DateTime(Immutable); these classes
> have not been designed for that; for instance (and that may actually be
> the only issue), __construct() is not called (<https://3v4l.org/4Y7jU>).
>

But interestingly __clone() is called: https://3v4l.org/A7Gd2

I agree that extending should not be the way to go. However, there are some
well known libraries that do it, like Carbon.


 Of course, we cannot easily make them final, but I don't think we
> should encourage users to subclass by documenting return types as static
> =E2=80=93 besides that the current return type is not wrong (it's just no=
t as
> specific as it could be).
>
> > If you agree that it's a doc bug, I'll submit a PR.
>
> As of PHP 8.0.0, the single-source-of-truth regarding the signatures are
> the stub files[1].  The signatures in the PHP manual can be
> automatically generated from these.  Therefore the stubs would need to
> be changed (first).
>
> [1] <https://github.com/php/php-src/blob/master/ext/date/php_date.stub.ph=
p
> >
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--00000000000006c5f305f15f1d4b--