On Wednesday, 2 October 2024 at 00:32, Larry Garfield <larry@garfieldtech.com> wrote:
I have no strong opinions on this RFC as I've not paid close attention to it, but "we can't introduce an unnamespaced class, that's a BC break" is simply not true, and not consistent with how Internals and the stdlib are and have been developed.
This is not a new class, it is a class that has existed since the PHP 4 days.
Arguably, if this would be a new class, that argument would have more merit.
But changing the name of class that is 20+ years old and could have been used in type declarations since possibly PHP 5.0 is a non-starter IMHO.
Best regards,
Gina P. Banyard
On 02.10.2024 at 12:55, Gina P. Banyard wrote:
On Wednesday, 2 October 2024 at 00:32, Larry Garfield <larry@garfieldtech.com> wrote:
I have no strong opinions on this RFC as I've not paid close attention to it, but "we can't introduce an unnamespaced class, that's a BC break" is simply not true, and not consistent with how Internals and the stdlib are and have been developed.
This is not a new class, it is a class that has existed since the PHP 4 days.
Plus it is not part of some rarely used extension, but rather of
ext/standard, so it is always available, and nobody had been able to
declare a userland class Directory (Online PHP editor | output for dUOq0).
Arguably, if this would be a new class, that argument would have more merit.
Right.
But changing the name of class that is 20+ years old and could have been used in type declarations since possibly PHP 5.0 is a non-starter IMHO.
I agree, although one could pursue the RFC process. This would be a
completely different RFC, though.
Christoph