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é