Hi Rowan and Larry,
> Isn't that exactly what a deprecation period is for?
>
Yes, sure, but I wrote my arguments with the "Short deprecation period" in
mind so that the removal of
these functions causes the least pain.
> If we want to give people longer, just leave the functionality deprecated
On Wed, Jun 21, 2023, at 11:57 AM, Rowan Tommins wrote:
> On Wed, 21 Jun 2023 at 09:43, Máté Kocsis 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'
On Wed, 21 Jun 2023 at 09:43, Máté Kocsis 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
Hi Bruce,
For those who use callbacks now, how is this in any way better? They will
> eventually end up using an OOP approach anyway (as that's the strategic
> goal).
> Migrating from `session_set_handler_callbacks()` would still be
> (potentially)
> non-trivial. And what's the point migrating *to
On Wed, Jun 21, 2023 at 12:54 AM Máté Kocsis wrote:
> * In order to finally achieve the strategic goal, we deprecate the old
> function along with session_set_handler_callbacks()
> as soon as the right time comes. That may be PHP 9.x or 10.y or 11.z,
> whatever.
For those who use callbacks now,
HI Nicolas and Rowan,
Mate, WDYT of 2)?
Your sentence about better typing rang a bell with me: I think that's the
best argument
for removing the signature accepting callables. But before coming to a
conclusion,
let me answer Rowan's question first:
This is where I don't understand what you or M
On Tue, 20 Jun 2023 at 09:22, Nicolas Grekas
wrote:
> > So are you saying we should deprecate the function-based version
> > completely, and not provide any new names at all? I think I would prefer
> > that to the confusing set of aliases the current RFC text proposes.
> >
>
> I was not but I wou
> Then, among both options, we need to select the one with the best future
> > proofness, and that's definitely the OOP one to me, because it comes with
> > more guarantees (type checks).
>
>
> So are you saying we should deprecate the function-based version
> completely, and not provide any new na
On 20/06/2023 07:26, Nicolas Grekas wrote:
Then, among both options, we need to select the one with the best future
proofness, and that's definitely the OOP one to me, because it comes with
more guarantees (type checks).
So are you saying we should deprecate the function-based version
complet
Le lun. 19 juin 2023 à 22:33, Rowan Tommins a
écrit :
> On 19/06/2023 21:17, Nicolas Grekas wrote:
> > I think we must account for a bit of history/legacy on the topic.
> > I think session_set_save_handler(SessionHandlerInterface) is the best
> BC/FC
> > path we can provide.
>
>
> Can you elabora
On 19/06/2023 21:17, Nicolas Grekas wrote:
I think we must account for a bit of history/legacy on the topic.
I think session_set_save_handler(SessionHandlerInterface) is the best BC/FC
path we can provide.
Can you elaborate? The SessionHandlerInterface is the *newer* of the two
current signat
Le mer. 14 juin 2023 à 23:51, Máté Kocsis a écrit :
> >
> > Given that you've agreed that neither signature is "primary" or "better",
> > doesn't that argument apply equally to both signatures? If it's OK to
> force
> > anyone using individual callbacks to change their code, why is it not
> > equ
On 14/06/2023 22:51, Máté Kocsis wrote:
The whole discussion about also deprecating the other one started only
because of improving naming:
it is also a nice thing to pursue but fails the cost-benefit analysis.
In my mind, making two new names, both unambiguous, gives a greater
benefit (a cle
>
> Given that you've agreed that neither signature is "primary" or "better",
> doesn't that argument apply equally to both signatures? If it's OK to force
> anyone using individual callbacks to change their code, why is it not
> equally OK to force anyone using an object to change their code?
>
A
On Tue, 13 Jun 2023 at 15:49, Máté Kocsis wrote:
> I understand that communication is much simpler with your suggested
> approach, however, deprecating something which everyone surely uses partly
> undermines the efforts we have made for ensuring as much backward
> compatibility as reasonably pos
>
> In my mind, the only reason to change anything about this function is that
> we can't properly overload a function based on its argument types. There's
> nothing particularly "primary" or "better" about either of the two
> signatures, it's just hard to document and use named parameters while
>
On 10 June 2023 08:31:24 BST, "Máté Kocsis" wrote:
>Hmm, that's also a very good idea, and I support this. However, I'm
>hesitant to deprecate the 2 parameter version of session_set_save_handler()
>just yet,
>since doing so would mean that everyone using sessions has to use a new
>function... Inst
I'm forwarding my mails which I managed to only address for Rowan:
Hi Rowan,
> If we go down that route, perhaps we should come up with a corresponding
> name for the object based version - "session_set_handler_object" perhaps?
> That would also mean the deprecation messages can be much simpler:
18 matches
Mail list logo
