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 

--Larry Garfield

PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to