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é
