Re: [RFC] [Discussion] Deprecate functions with overloaded signatures

On Wed, Jun 14, 2023 at 4:06 AM Derick Rethans <derick@php.net> wrote: > > On Tue, 13 Jun 2023, Nicolas Grekas wrote: > > > > I'm going to nitpick on the newly suggested names and argument order for > > > the > > > DatePeriod factory methods — althoughI do agree that they need to get > > > created: > > > > > > createFromInterval(DateTimeInterface $start, DateInterval $interval, > > > DateTimeInterface $end, int $options = 0) > > > → createWithRange(DateTimeInterface $begin, DateTimeInterface $end, > > > DateTimeInterface $int, int $options = 0) > > > > > > createFromRecurrences(DateTimeInterface $start, DateInterval $interval, > > > int $recurrences, int $options = 0) > > > → createWithRecurrences(DateInterval $begin, int $recurrences, > > > DateInterval $interval, int $options = 0) > > > > > > We also should fix the argument names. Either $start/$finish, or > > > $begin/$end. I > > > prefer the latter. > > > > > > createFromIso8601(string $specification, int $options = 0) > > > -> createFromISO8601String > > > > > > I am open to bike shedding about this :-) > > > > > > > On my side, I'd very much prefer keeping the constructor of DatePeriod and > > thus making it non-overloaded with this signature: > > > > public function __construct(DateTimeInterface $start, DateInterval > > $interval, DateTimeInterface|int $end, int $options = 0) {} > > That still has an overloaded third argument — DateTimeInterface|int. This specific case is not that problematic. Since things need untangling anyway, I would feel free to improve it if something is done, but it's not much of a problem. The problem is when there's a wildly different signature, or if args change the return type structure, etc. So in this case, the problem is really: public function __construct(string $isostr, int $options = 0) {} Which can't really be unified with the others very well.