Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120660
Date: Thu, 22 Jun 2023 12:53:23 +0100 (BST)
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
cc: PHP Internals List <internals@lists.php.net>
In-Reply-To: <CAOWwgpniYotForXo_UCdkriOTo-jz0HhdydLLNo18bBt3HKJqA@mail.gmail.com>
Message-ID: <22541969-c914-c7d2-e1c6-d3b9bf674236@php.net>
References: <CAH5C8xXtCVHaxwzmAW_eBxp_D6p7kww9svND=3AEeC9X6--YXg@mail.gmail.com> <eaaa805e-86b2-ce8c-5a24-c301260d16ac@php.net> <CAOWwgpn3PY=4DQ7s2PxjET7__fx09wYqQOJR76L2owa9PX9tFA@mail.gmail.com> <017db925-da75-8054-7a35-c65457cd03ae@php.net>
 <CAOWwgpniYotForXo_UCdkriOTo-jz0HhdydLLNo18bBt3HKJqA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-21572663-1687434803=:36424"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded
 signatures
From: derick@php.net (Derick Rethans)

--8323329-21572663-1687434803=:36424
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Mon, 19 Jun 2023, Nicolas Grekas wrote:

> > > On my side, I'd very much prefer keeping the constructor of=20
> > > DatePeriod and thus making it non-overloaded with this signature:
> > >
> > > public function __construct(DateTimeInterface $start, DateInterval=20
> > > $interval, DateTimeInterface|int $end, int $options =3D 0) {}
> >
> > That still has an overloaded third argument =E2=80=94 DateTimeInterface=
|int.
> >
> > Where you trying to suggest to change the current existing=20
> > __construct() to:
> >
> > public function __construct(DateTimeInterface $start, DateInterval
> > $interval, DateTimeInterface $end, int $options =3D 0)
> >
> > and then add these two new factory methods?
> >
> > createFromRecurrences(DateTimeInterface $start, DateInterval $interval,
> > int $recurrences, int $options =3D 0)
> >
> > createFromISO8601String(string $specification, int $options =3D 0)
> >
>=20
> I really meant DateTimeInterface|int, not an overloaded signature but a
> union type.

You may call it a union type, but that's still an overloaded signature :-)

> My concern is about providing the best path forward. Both deprecating=20
> and providing the alternative in the same version creates a lot of=20
> friction for end users.
>
> After a quick chat with Mate, I think we should do this union type *in=20
> addition* to adding the new static constructors.
>
> Then, later on, if future us think it's worth it, we might want to=20
> consider deprecating passing an integer.
>
> This would provide a path for BC/FC I would fully support.

In any case, I don't mind this =E2=80=94 I'm actually going to suggest to c=
hange=20
the constructor to:

public function __construct(DateTimeInterface $start, DateInterval $interva=
l, DateTimeInterface|int $end, int $options =3D 0) {}

And then *only* add:

public static function createFromISO8601String(string $specification, int $=
options =3D 0): static {}

This solves the original problem of not being able to define the=20
signatures in stubs, and also extracts the most problematic of methods=20
into a factory method where it should always have belonged.

There would be no additional benefit in creating the other two factory=20
methods.

cheers,
Derick
--8323329-21572663-1687434803=:36424--