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

From: Date: Tue, 13 Jun 2023 21:02:34 +0000
Subject: Re: [RFC] [Discussion] Deprecate functions with overloaded signatures
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-120568@lists.php.net to get a copy of this message
Hi Nicolas, 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'd help a lot with the migration/BC path and this signature also just > makes sense. > I completely agree with this (more so since this used to be the original proposal), so I'll ask Derick again about his stance on this. Unrelated: I don't think adding "ReflectionMethod::createFromMethodName" is > useful. Using explode is just fine for those that need this style. And > since this is the recommended migration path, better not give a reason to > change twice the code. > I don't really mind removing ReflectionMethod::createFromMethodName, so if anyone has a use-case which heavily relies on creating the reflection method from a callable name ("Class::method" format), now is the time to speak up for this method. As far as I see the relevant impact analysis file ( https://gist.github.com/kocsismate/b457f8fef074039b58fbee9121d05e92), Laminas, Symfony and Nette DI would also be impacted by the removal. I don't think that it causes a big problem to explode the string instead, but I'm wondering if performance sensitive code may be negatively affected (?). Thank you, Nicolas, for your insights! Máté

« previous php.internals (#120568) next »