On Wed, Jun 21, 2023, at 11:57 AM, Rowan Tommins wrote: > On Wed, 21 Jun 2023 at 09:43, Máté Kocsis <kocsismat...@gmail.com> wrote: > >> The reason why I think it's a good approach to have an intermediate state >> is to give >> these people the possibility to defer the actual migration until the >> very end. >> > > > Isn't that exactly what a deprecation period is for? > > If we want to give people longer, just leave the functionality deprecated > for longer before removing it. If we want to phase that in gradually, start > with a documentation-only deprecation, and add the deprecation notice later. > > If the plan is to keep the current function name, we can't get any of the > (very small) benefits of removing the extra signature until the final > removal anyway. > > Regards, > -- > Rowan Tommins > [IMSoP]
I'm inclined to agree here, I think. I am all for a very-long grace period to give people lots of time for this change, but if the end state is just the object version being supported, then adding functions in the mean time doesn't make sense to me. I'd propose a doc-only deprecation now (with session_set_handler() added for the object version), an E_DEPRECATED in 9.0, and full removal in 10.0. Assuming the expected release schedule, that gives people ~2 years before they see even an E_DEPRECATED, and 6-7 years before they are forced to change. That should be ample time for anyone that still needs to make the switch. (A generic "functions to object wrapper" class is probably a not-too-hard composer package for someone to write, either, but that's not a task for internals.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
